#38 IOCP backend in win32

open
nobody
None
5
2010-05-09
2010-01-14
Anonymous
No

Discussion

1 2 > >> (Page 1 of 2)
  •  
    Attachments
  • Nick Mathewson
    Nick Mathewson
    2010-01-14

    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.

     
  • Chris Davis
    Chris Davis
    2010-01-29

    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.

     
  • Nick Mathewson
    Nick Mathewson
    2010-01-30

    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.

     
  • Chris Davis
    Chris Davis
    2010-01-31

    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.

     
  • Chris Davis
    Chris Davis
    2010-02-05

    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.)

     
  • Nick Mathewson
    Nick Mathewson
    2010-02-05

    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.

     
  • Chris Davis
    Chris Davis
    2010-02-06

    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.

     
  • Chris Davis
    Chris Davis
    2010-02-06

    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.

     
  • Chris Davis
    Chris Davis
    2010-02-10

    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. "

     
1 2 > >> (Page 1 of 2)