apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: APR_POLLHUP?
Date Mon, 12 May 2003 20:29:39 GMT

  this question, as you pointed out, is much broader than Win32.

  We could implement a peek-ahead, but that still won't tell you if the client
disconnected a little later (such as 4000 bytes later.)  And it will slow things

  I suspect that you/we are best off keeping the current behavior, and simply
following through with the appropriate apr_socket_send/recv() to determine if
things are off-kilter.  Stevens indicates that a number of events in poll() are
implementation-dependent, so coding on the safe-side seems like a better
practice.  In other words, be prepared that POLLIN may be toggled when
non-recv events are pending, such as socket errors or hangup.


At 09:22 AM 5/12/2003, Saxon Druce wrote:
>About a year ago I wrote a networking app using apr. I'm now updating to the
>latest version, which means moving to the new poll API.
>In the old API, in Win32 or if HAVE_POLL wasn't defined in Unix,
>apr_poll_revents_get() would do a 1-byte 'peek recv' to see if a socket
>being in the read set after select() was actually APR_POLLHUP, APR_POLLNVAL
>or APR_POLLERR, as opposed to the standard APR_POLLIN which being in the
>read set is generally for.
>With the new API this isn't done, meaning APR_POLLHUP would never be in the
>value returned by apr_poll_revents_get(). Is getting an APR_POLLIN following
>by an apr_recv() which doesn't return APR_SUCCESS now the correct way to
>detect that the connection has been closed?
>Is it a portability issue that in Unix if HAVE_POLL is defined (meaning
>poll() gets used) APR_SIGHUP may be returned, when in other situations
>(Win32 or !HAVE_POLL) it can't be?

View raw message