RE: recv and errno during a connection reset/closed by peert
On Wed, 30 Mar 2005, Brian Ford wrote: On Tue, 29 Mar 2005, Peter A. Castro wrote: On Tue, 29 Mar 2005, Brian Ford wrote: On Tue, 29 Mar 2005, Peter Stephens wrote: I have thought about your suggestion and it makes a lot of sense. It seems like your suggestion would be very portable. A good suggestion and the most likely route for me at this point. Not to me. Maybe I'm missing something, but it seems you are going to a lot of effort to poorly recreate poll/select? Why? A zero length return on a stream socket always means that the peer has closed its socket for writing. It may, however, still be open for reading (I don't remember the syscalls for doing such, but it can be done). And I'm saying experience shows to the contrary. A zero return on a datagram socket always means that a zero length message has been received. We're talking stream, not datagram here. Counting zero returns is a poor hack at best and makes no sense to me since it never gives you any more information. Considering its a very simply solution to a real problem, what makes it a poor hack? If you are doing sequential, non multi-plexed, reads why do poll or select? You don't need to. Sitting in read is more optimal and the read should return either data or an error. Ok. The flaw in recv is that it returns a non-error non-data status. It's not a flaw, it's the design (see above). Yes, and I've never been very happy with it. If the connection was closed and there's no more data left to return, I'd prefer recv returned -1 with ENODATA or ENOTCONN for the errno. But, it's not likely recv's semantics will ever be changed. Perhaps it would be better to switch to using read() instead of recv? They usually have exactly the same semantics. Note the word "usually". Not "always". -- Brian Ford -- Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> "Cats are just autistic Dogs" -- Dr. Tony Attwood -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: recv and errno during a connection reset/closed by peert
On Tue, 29 Mar 2005, Peter A. Castro wrote: > On Tue, 29 Mar 2005, Brian Ford wrote: > > On Tue, 29 Mar 2005, Peter Stephens wrote: > >> I have thought about your suggestion and it makes a lot of sense. > >> > >> It seems like your suggestion would be very portable. A good > >> suggestion and the most likely route for me at this point. > > > > Not to me. Maybe I'm missing something, but it seems you are going to a > > lot of effort to poorly recreate poll/select? > > Why? A zero length return on a stream socket always means that the peer has closed its socket for writing. It may, however, still be open for reading (I don't remember the syscalls for doing such, but it can be done). A zero return on a datagram socket always means that a zero length message has been received. Counting zero returns is a poor hack at best and makes no sense to me since it never gives you any more information. > If you are doing sequential, non multi-plexed, reads why do poll or > select? You don't need to. > Sitting in read is more optimal and the read should return > either data or an error. Ok. > The flaw in recv is that it returns a non-error non-data status. It's not a flaw, it's the design (see above). > Perhaps it would be better to switch to using read() instead of recv? They usually have exactly the same semantics. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: recv and errno during a connection reset/closed by peert
On Tue, 29 Mar 2005, Brian Ford wrote: On Tue, 29 Mar 2005, Peter Stephens wrote: I have thought about your suggestion and it makes a lot of sense. It seems like your suggestion would be very portable. A good suggestion and the most likely route for me at this point. Not to me. Maybe I'm missing something, but it seems you are going to a lot of effort to poorly recreate poll/select? Why? If you are doing sequential, non multi-plexed, reads why do poll or select? Sitting in read is more optimal and the read should return either data or an error. The flaw in recv is that it returns a non-error non-data status. Perhaps it would be better to switch to using read() instead of recv? This is really getting off-topic, though. Yes. Isn't it fun ?-) -- Brian Ford -- Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> "Cats are just autistic Dogs" -- Dr. Tony Attwood -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
