From dev-return-9788-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Mon May 12 20:43:51 2003 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 4610 invoked by uid 500); 12 May 2003 20:43:51 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 4598 invoked from network); 12 May 2003 20:43:50 -0000 Errors-To: Message-Id: <5.2.0.9.2.20030512150955.027f9ce8@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 12 May 2003 15:29:39 -0500 To: "Saxon Druce" From: "William A. Rowe, Jr." Subject: Re: APR_POLLHUP? Cc: "APR dev" In-Reply-To: <027b01c31891$f2193a50$82db26cb@saxon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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