The Haskell code codexon used isn't the best Haskell can do. But I think it's the clearest, most obvious code---the most like what someone learning from the ground up would try first. Ideally, it should run fast by default, and it's too bad that you need to learn about bytestrings (and choose between lazy vs. strict), the various utf8 encoding options, and a new event library to make it perform. Since I'm basically a beginner to Haskell, if I were to set out to test out a WebSocket server in Haskell, my first pass code would probably look a lot like the codexon template. I certainly wouldn't want to go multi-process nor explicitly manage cores within a single process. I would want forkIO to just work.

So it's very nice to hear that it looks like GHC will be getting efficient event-driven IO-blocked thread awakening. The naive code will work better. In my head, disk IO fits in because if a naively-written thread decides to read from the disk, we don't want 20,000 concurrent network-bound threads to be affected by it, but upon reflection I think the concern isn't too justified.

Aran

On Sun, May 2, 2010 at 1:55 AM, Donn Cave <donn@avvanta.com> wrote:

>>> 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@avvanta.com

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe