[Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Fri Jan 21 07:51:09 EST 2005


On Fri, 2005-01-21 at 12:33 +0000, Keean Schupke wrote:
> Glynn Clements wrote:
> 
> > The central issue is that the Unix API doesn't distinguish between
> >
> >cases 1 and 2 when it comes to non-blocking I/O, asynchronous I/O,
> >select/poll etc. [OTOH, NT overlapped I/O and certain Unix extensions
> >do distinguish these cases, i.e. data is only "available" when it's in
> >physical RAM.]
> >
> >  
> >
> This is in direct contradiction to  the documentation for select. Select
> specifically says it returns if a handle in the read list would _not_ block
> on a read call.

The point is that the Unix documentation does not consider the short
pause as data is read off your hard drive to be blocking. So that's why
select will always report that data is available when you use it with a
file handle.

It considers blocking only to be pauses of indefinite length like you
can get when reading from pipes or sockets. Since in that case you
depend on the writer end getting round to giving you more data, whereas
the kernel considers data in a file to be always available.

Of course as people have pointed out this is not a terribly helpful
assumption for slow devices and does not allow overlapping IO with
processing. The only way to get that is to use other OS APIs dedicated
to async/overlapped IO or to use OS threads.

Duncan



More information about the Haskell-Cafe mailing list