Saxon, 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 down. 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. Bill At 09:22 AM 5/12/2003, Saxon Druce wrote: >Hi, > >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? > >cya, >Saxon
