APR_POLLHUP?

[Saxon Druce <sa...@blocksoftware.com>]

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

Re: APR_POLLHUP?

[Saxon Druce <sa...@blocksoftware.com>]

Hi Bill,

Ok, thanks. Should a comment be added to apr_poll.h somewhere, eg on
apr_poll() and apr_pollset_poll()? I can do this and submit it as a patch if
you'd like.

Also, should this code in apr_poll() for !HAVE_POLL:

if (aprset[i].reqevents & APR_POLLIN) {
    FD_SET(fd, &readset);
}
if (aprset[i].reqevents & APR_POLLOUT) {
    FD_SET(fd, &writeset);
}
if (aprset[i].reqevents &
    (APR_POLLPRI | APR_POLLERR | APR_POLLHUP | APR_POLLNVAL)) {
    FD_SET(fd, &exceptset);
}

Actually be this:

if (aprset[i].reqevents & (APR_POLLIN | APR_POLLHUP)) {
    FD_SET(fd, &readset);
}
if (aprset[i].reqevents & APR_POLLOUT) {
    FD_SET(fd, &writeset);
}
if (aprset[i].reqevents &
    (APR_POLLPRI | APR_POLLERR | APR_POLLNVAL)) {
    FD_SET(fd, &exceptset);
}

?

(And similar in apr_pollset_add()). Although according to my 'man poll',
only POLLIN, POLLOUT and POLLPRI should be in the requested events anyway.

I've also noticed that if the APR_POLLPRI event is requested, the socket is
added to the except set in select() (as it should be), but if it is
signalled, the returned event is APR_POLLERR. I don't use APR_POLLPRI to
know what is appropriate though.

cya,
Saxon

----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: "Saxon Druce" <sa...@blocksoftware.com>
Cc: "APR dev" <de...@apr.apache.org>
Sent: Tuesday, May 13, 2003 4:29 AM
Subject: Re: APR_POLLHUP?


> 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
>

Re: APR_POLLHUP?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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