Re: RESEND: PATCH: Update requested events for a descriptor that is already in a poll set

=27655 Rob. -- Robert Norris GPG: 1024D/FC18E6C2 Email+Jabber: [EMAIL PROTECTED]Web: http://cataclysm.cx/ signature.asc Description: Digital signature

Re: RESEND: PATCH: Update requested events for a descriptor that is already in a poll set

right. I'll see about getting an updated patch that incorporates these changes. Thanks for the feedback! Rob. -- Robert Norris GPG: 1024D/FC18E6C2 Email+Jabber: [EMAIL PROTECTED]Web: http://cataclysm.cx/ signature.asc Description: Digital

RESEND: PATCH: Update requested events for a descriptor that is already in a poll set

. The only problem with this is that such a pointer would really belong in apr_pollfd_t, except that its specific to the poll() implementation, and that type is not opaque. So I'd appreciate some pointers on how to best do this. Rob. -- Robert Norris GPG: 1024D

Re: PATCH: Determine how many bytes are waiting to be read from a socket

. -- Robert Norris GPG: 1024D/FC18E6C2 Email+Jabber: [EMAIL PROTECTED]Web: http://cataclysm.cx/ signature.asc Description: Digital signature

Re: PATCH: Determine how many bytes are waiting to be read from a socket

On Thu, Mar 04, 2004 at 06:04:05PM -0600, Scott Lamb wrote: On Mar 4, 2004, at 4:51 PM, Robert Norris wrote: I use this to determine if the peer has closed the connection. In that case, the socket goes readable, and this function reports 0 bytes waiting. I don't think this is correct

Re: PATCH: Determine how many bytes are waiting to be read from a socket

On Thu, Mar 04, 2004 at 07:39:48PM -0600, Scott Lamb wrote: On Mar 4, 2004, at 6:44 PM, Robert Norris wrote: The connection is only closed if the socket is readable and there's no bytes waiting. The results of select()/poll() are undefined unless they return successfully. I'm saying that I

PATCH: Update requested events for a descriptor that is already in a poll set

, except that its specific to the poll() implementation, and that type is not opaque. So I'd appreciate some pointers on how to best do this. Rob. -- Robert Norris GPG: 1024D/FC18E6C2 Email+Jabber: [EMAIL PROTECTED]Web: http://cataclysm.cx

PATCH: Determine how many bytes are waiting to be read from a socket

, because functions in sendrecv.c assume this too. Rob. -- Robert Norris GPG: 1024D/FC18E6C2 Email+Jabber: [EMAIL PROTECTED]Web: http://cataclysm.cx/ diff -U3 -r /home/box/downloads/apr-0.9.4/configure.in apr-0.9.4/configure.in --- /home/box/downloads

RESEND: Deficiencies in the poll and/or socket APIs

sure I'm going down the right path before I start. Please let me know what the best course of action is here. Regards, Rob. [1] http://www.greenend.org.uk/rjk/2001/06/poll.html -- Robert Norris GPG: 1024D/FC18E6C2 Email+Jabber: [EMAIL PROTECTED

Re: RESEND: Deficiencies in the poll and/or socket APIs

. Thanks, Rob. -- Robert Norris GPG: 1024D/FC18E6C2 Email+Jabber: [EMAIL PROTECTED]Web: http://cataclysm.cx/ signature.asc Description: Digital signature

Deficiencies in the poll and/or socket APIs

, Rob. -- Robert Norris GPG: 1024D/FC18E6C2 Email+Jabber: [EMAIL PROTECTED]Web: http://cataclysm.cx/ signature.asc Description: Digital signature

Re: Deficiencies in the poll and/or socket APIs

Getting a POLLHUP event from the poll call also seems to work in some places, but its not really portable[1], and APR does it differently again. Bah, forgot the reference. Sorry. [1] http://www.greenend.org.uk/rjk/2001/06/poll.html -- Robert Norris GPG