apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Re: 100% cpu with APR on Windows
Date Sun, 29 May 2011 20:53:04 GMT
On Fri, May 27, 2011 at 3:59 PM, Justin Erenkrantz
<justin@erenkrantz.com> wrote:
> On Fri, May 27, 2011 at 9:48 AM,  <trawick@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)

View raw message