On Fri, May 27, 2011 at 3:59 PM, Justin Erenkrantz <jus...@erenkrantz.com> wrote: > On Fri, May 27, 2011 at 9:48 AM, <traw...@gmail.com> wrote: >> Can you outline the idioms you refer to that prefer a select() >> implementation? >> >> iow, how different are they from >> >> apr_socket_create >> set socket nonblocking with no timeout >> apr_socket_connect() >> apr_pollset_poll() > > That's all serf is doing. With WSAPoll(), if you connect to a port > via a non-blocking socket that there is no listener on, WSAPoll() > never sends any indication. However, select() lets you know that the > earlier connect() failed. Given the pretty isolated test case in the > forum earlier, I do think this is an underlying issue with WSAPoll() - > but enough of an issue, it shouldn't be the default unless someone can > find a way to get WSAPoll() to report failure... -- justin
no-can-do AFAICT; there's literally NOTHING you can put in .events which results in anything reported in .revents after ECONNREFUSED your two cases are the only reports of WSAPoll() problems I know of in the last year (since 1.4.x was released, making WSAPoll() the default); still, it seems probable that more code works with a select()-based implementation a new WSAEVENT-based implementation may be the long term solution (FD_CONNECT events would have to be mapped to something the app would ask for; presumably FD_CLOSE events would map to POLLHUP, which was the select() issue which started this thread)
