[Haskell-cafe] are forkIO threads event-driven?

[Donn Cave]

>>> In GHC, if a thread spawned by forkIO blocks on some network or
>>> disk IO, is the threading system smart enough not to wake the thread

... "disk IO", you say?

Most platforms support asynchronous I/O for what UNIX calls `slow'
devices - pipe, tty, Berkeley socket.  Select, poll, kqueue, O_NDELAY,
your pick - all stuff that has been semi-standard for decades.  I've
corresponded with people who are convinced it works on disk files,
but I don't know where that idea got started, it doesn't far as I know.

Old timer OSes (like VMS, sorry VMS fans!) supported asynch on disks,
but I guess by the time UNIX got to the point where there might have
been money in standardized asynchronous disk I/O support, disks were
fast enough that most out-of-the-box users didn't care.  If GHC has
been plugging into asych disk I/O features, it would be really
interesting to know how far it goes.  Enabled by default?  Works
on which platforms, and devices - e.g., NFS filesystems?

I've never worked on anything where a single process needed to
have access to all available computer resources all the time,
but it seems like a pretty tough job to tackle - eventually you
end up pretty near the `real time' lifestyle, where you can't
afford to have page faults and so forth.  In real applications,
I'm sure it's usually good enough to dispatch around slow
devices, and let things back up for the brief moments that
it takes to open(), read() etc. a disk file.  But if you really
need everything, I think multiple processes (or threads) might
be the only sane way to go.

	Donn Cave, donn at avvanta.com