Ben Rudiak-Gould wrote: > >Actually, If I were writing new haskell libraries, I would use mmap > >whenever I could for accessing files. not only does it make the file > >pointer problem go away, but it can be drastically more efficient. > > I'm not sure this is a good idea, because GHC really needs non-blocking > I/O to support its thread model, and memory-mapped I/O always blocks.
If, by "blocks", you mean that execution will be suspended until the data has been read from the device into the buffer cache, then Unix non-blocking I/O (i.e. O_NONBLOCK) also blocks. Calling read() on a descriptor which corresponds to a regular file won't report EAGAIN, even if the file is on a particularly slow device (floppy, CD-ROM, NFS etc). Essentially, reading data from regular files is always deemed to occur "soon", so the usual mechanisms for dealing with "slow" I/O (i.e. pipes, FIFOs, character devices, sockets) don't work. This applies equally to non-blocking I/O (O_NONBLOCK), asynchronous I/O (O_ASYNC), select(), poll() etc. In that regard, mmap()ed I/O is no better or worse than conventional non-blocking I/O. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
