Date:	Wed, 10 Mar 1999 16:19:57 +0100
From:	Frank Heckenbach <frank AT tim DOT gerwinski DOT de>
Message-Id:	<57676CAB.19990310161957.FOO-3B3F.frank@goedel.fjf.gnu.de>
X-Mailer:	smtphack 0.3.3 by Jan Andres
To:	eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com, peter AT gerwinski DOT de
Subject:	Re: Patch for select()
X-Counter:	894 peter AT gerwinski DOT de
Reply-To:	djgpp-workers AT delorie DOT com

> > > 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.
> 
> Yes, but in what real-life situation is this important?  I believe you
> said that you encountered the problem while porting GPC.

Not GPC itself, but Pascal code compiled with GPC.

> So where did
> GPC need to `select' to return `ready' at EOF?

E.g., the following situation: the program has a list of files to
read from (terminals and pipes, and since Dos doesn't know pipes,
they're emulated with disk files on DJGPP).

The code calls select() in a loop, then does (the Pascal equivalent
of) read() on the selected file. If it reads some data, fine, and if
it returns 0 for a pipe, the code knows the pipe is at its end
(i.e., has been closed at the other end -- this corresponds to EOF
with the DJGPP files), and removes it from the list.

If select() doesn't return `ready' in this case, it will finally
wait forever, after all files have been read completely.

IOW, as far as I understand the semantics of select(), when it says
`ready', it means: you can do a read() now and it won't block --
it'll either read some data, or return 0 to indicate "EOF", or
return an error status.

Frank

-- 
Frank Heckenbach, frank AT fjf DOT gnu DOT de
http://fjf.gnu.de/
PGP and GPG keys: http://fjf.gnu.de/plan

- Raw text -