Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 30 Mar 2005 20:54:31 -0800 (PST) From: "Peter A. Castro" To: cygwin AT cygwin DOT com cc: Peter Stephens Subject: RE: recv and errno during a connection reset/closed by peert In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-IsSubscribed: yes 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 or "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/