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

[Duncan Coutts]

On Fri, 2005-01-21 at 16:26 +0000, Keean Schupke wrote:
> Udo Stenzel wrote:
> >Thus the question is, does select() reliably tell if read() would block or does it
> >check for something else?  Is the documentation wrong (on some platforms)?
> >  
> >
> Having read around I have found that select does return readable for all
> file IO on a block device...
>
> I wonder if ghc could use non-blocking mode (files opened with the 
> O_NONBLOCK) flag? In which case you just do the read, and it returns
> immediately with the current contents of the buffer (up to the size in
> the read argument)... The sheduler could allow one chance at reading,
> then give the other haskell-threads a go whilst more data comes in.

In 6.2 (and in 6.4 without the threaded RTS) this is what ghc already
does. It opens all files in non-blocking mode, when a Haskell thread
does a read, if that read would have blocked the thread is suspended and
another thread is scheduled. The Haskell thread that did the read only
becomes runnable again when select() indicates that there is more data
available.

However as people have said disk files are considered never to block so
all this scheduling stuff will only happen for Haskell threads that are
reading from pipes or sockets.

I think you're still confused about what non-blocking means under the
traditional unix interpretation. It does not guarantee that all you have
to wait for is for some disk buffer to be copied into your address space
(ie hardly any time at all). It may mean waiting for as long as it takes
to schedule an IO read, seek, perform dma transfer and then copy the
data to your address space. (Writing on the other hand is pretty
instantaneous so long as there is kernel IO buffer space available)

Duncan