Xref: utzoo comp.unix.programmer:2169 comp.unix.questions:32479
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!ogicse!sequent!muncher.sequent.com!news
From: bridej@sequent.com (Jim Bride)
Newsgroups: comp.unix.programmer,comp.unix.questions
Subject: Re: why would a socket read() set errno to EWOULDBLOCK but still read?
Message-ID: <1991Jun28.174032.3872@sequent.com>
Date: 28 Jun 91 17:40:32 GMT
References: <1991Jun27.220701.21108@athena.mit.edu>
Sender: news@sequent.com (News on Muncher)
Distribution: usa
Organization: Sequent Computer Systems, Inc.
Lines: 23

mlevin@jade.tufts.edu writes:


>   I am doing a read() on a connected TCP socket (BSD 4.3) marked as
>non-blocking. For some reason, the read returns the proper number of
>characters read (or sometimes 0), but sets errno to EWOULDBLOCK. Why
>is this? My program never did this before; I was under the impression
>that if no data was available, it should return -1. Is this a possible
>event, or am I trashing memory somewhere? Please reply to
>mlevin@jade.tufts.edu. 

According to the man page, when you set the descriptor for the socket as
non-blocking (ie with the FNDELAY flag to fcntl()), the read will return
EWOULDBLOCK to let you know that the operation would have blocked had under
normal circumstances.  You read definitely should be returning -1 (at least
this is how it works under Dynix and SunOS.)   It sounds like there might be
a bug in read() on your machine.  I'd be interested to find out what was
causing your problem.
 
>Mike Levin

- Jim Bride	bridej@sequent.com	
----------------------------------------------------------------------------