Hello, > Can you test that using socket and this instead of the send in evpipe_write > works maybe? You mean write(), I suppose, and yes, that code works (copied verbatim). In fact, even a plain call to send() works:
send (EV_FD_TO_WIN32_HANDLE (evpipe [1]), &(evpipe [1]), 1, 0); > If that works in your case, it would get rid of EV_USE_WSASOCKET entirely. I am not really bothered by EV_USE_WSASOCKET (I need EV_SELECT_IS_WINSOCKET in any case, so one extra macro is not a big deal) as long as I can just use the upstream libev source code - saves me some merging effort. > We might still need similar code for WSARecv instead of read in the receive > path though. Definitely - my original patch proposal was incomplete (as pointed out by malek), since it did not change the receive path, and the read() call inside pipecb() failed in exactly the same way (except that the ReadFile() function was the culprit - its documentation lists constraints similar to those of WriteFile()). However, that behavior was somewhat not that visible, since signaling the async watcher worked, and the handling on the other side was fine too, but no data was ever really read from the socket, so the latter was always ready for receiving, the select() call returned immediately indicating that, and the program started looping constantly. Yours faithfully, Anton Kirilov _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
