Sender: nate AT cartsys DOT com
Message-ID: <36E582FB.9748E70@cartsys.com>
Date: Tue, 09 Mar 1999 12:22:19 -0800
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.1 i586)
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Patch for select()
References: <2CE741E0 DOT 19990309160234 DOT FOO-AB9 DOT frank AT goedel DOT fjf DOT gnu DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Frank Heckenbach wrote:
> 
> > > while porting some GPC code to DJGPP, I found that select() has
> > > different semantics regarding end of file under DJGPP than under
> > > Un*x. DJGPP's select() returns `not ready' at the end of a regular
> > > file (i.e., no character device under Dos), but select() under Un*x
> > > returns `ready' in this situation (verified under Linux and
> > > Solaris).
> >
> > Could you please elaborate under what circumstances does this make a
> > difference?
> 
> Whenever a disk file is at EOF, like the test program I included.
> Unpatched select() returns `not ready', but the patch makes it say
> `ready', like it does under Un*x.

For clarification: this is correct.  The semantics of `select', as I
understand them, consider a file to be "ready" whenever an attempt to do
I/O on it would not block, even if it would fail.  For instance, if
writing to a pipe and the buffer is full, the `write' call would wait
(block) until the buffer had space again, do the write, and return.  If
you read at the end of a file, the `read' will return immediately
(having read 0 bytes), hence the file is "ready".
-- 

Nate Eldredge
nate AT cartsys DOT com