Xref: utzoo comp.unix.programmer:2171 comp.unix.questions:32492
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!hwajin
From: hwajin@sgi.com (Hwa-jin Bae)
Newsgroups: comp.unix.programmer,comp.unix.questions
Subject: Re: why would a socket read() set errno to EWOULDBLOCK but still read?
Message-ID: <1991Jun28.195655.25623@odin.corp.sgi.com>
Date: 28 Jun 91 19:56:55 GMT
References: <1991Jun27.220701.21108@athena.mit.edu> <4597@polari.UUCP>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: hwajin@pei.com
Distribution: usa
Organization: Protocol Engines, Inc.
Lines: 23
In-Reply-To: 6sigma2@polari.UUCP's message of 28 Jun 91 04: 31:48 GMT

>>>>> On 28 Jun 91 04:31:48 GMT, 6sigma2@polari.UUCP (Brian Matthews) said:

Brian> |   I am doing a read() on a connected TCP socket (BSD 4.3) marked as
Brian> |non-blocking. For some reason, the read returns the proper number of
Brian> |characters read (or sometimes 0), but sets errno to EWOULDBLOCK.

Brian> Errno is only valid if the read fails.  If the read succeeds, the
Brian> value of errno shouldn't be used.


i think the original poster is knowledgable enough to know that.
read() on a non-blocking socket can still return EWOULDBLOCK if
the amount of bytes read is less than the amount of bytes requested.
usually, programs that do non-blocking I/O would ignore this error
and try again, if necessary.



*hwajin


--
protocol engines, inc.