That patch is against Libevent 1.4.x. The "stable" means that we try not to do bugfixes only. Somebody would need to port it to the Libevent 2.0 backend API. I think Chris may have expressed interest.
Yes, I've started to port/rewrite this. The design is going to be a little different, but it'll be the same basic idea.
Neat. Let me know if you have any git branches for me to look at, or if you just want to chat about what you're doing here.
We discussed using a thread pool to monitor event objects to get around the MAXIMUM_WAIT_OBJECTS limit, so that's one thing I'm trying to implement. When there's working code, I'll send a link.
Looks like there's a good chance we won't need any special flags like EV_CONNECT, etc. getsockopt() should be enough to tell us what we need to know about a socket (whether the socket is UDP or TCP, if the TCP socket is a listener or is connected/unconnected.)
That's pretty good news!
wrt tcp socket issues, I worry about the transition from "unconnected" to "connected": For every other kind of transition, we should have an evmap_io_del/evmap_io_add pair to tell us that the socket we're talking about now may be of a different kind than it was before. But if a socket becomes connected, then the user is under no obligation to do anything the backend will see. I suppose that we can remember that the socket _was_ unconnected, and check it again every time the appropriate event triggers on it.
Yea, monitoring unconnected sockets to see when they become connected is important. When an unconnected socket is added to the IOCP backend, it waits for FD_CONNECT before launching overlapped I/O (assuming the connection was successful). If the socket was registered with EV_WRITE, the write event handler is called when the connect completes. If the connection fails, I think the backend should continue monitoring the socket for connect events because the user may try to connect the socket again.
Another issue is how to delete events that have pending overlapped I/O. CancelIo() might be useful, but it needs to be run in the same thread that initiated the overlapped operation.
Working on getting unit tests to work. It seems that WSAEventSelect behaves a bit differently than select, especially w.r.t. FD_WRITE. UDP sockets must be passed thru connect() first before FD_WRITE works. This behavior breaks the main/many_events test.
Also from MSDN:
"An FD_WRITE network event is recorded when a socket is first connected with connect/WSAConnect or accepted with accept/WSAAccept, and then after a send fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE network event setting and lasting until a send returns WSAEWOULDBLOCK. After such a failure the application will find out that sends are again possible when an FD_WRITE network event is recorded and the associated event object is set. "
This is languishing because of an issue that Chris ran into where a write(0) will actually always succeed immediately, and so doing EV_WRITE checks with IOCP isn't actually viable.