apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Saxon Druce" <sa...@blocksoftware.com>
Subject Re: APR_POLLHUP?
Date Tue, 13 May 2003 02:05:42 GMT
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." <wrowe@rowe-clan.net>
To: "Saxon Druce" <saxon@blocksoftware.com>
Cc: "APR dev" <dev@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
>


Mime
View raw message