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

[Aran Donohue]

That's very interesting. I only brought it up because I'm thinking about the
upcoming problems of real-time web application servers.

I'm sure many people have seen this blog post and Dons's replies:
http://www.codexon.com/posts/debunking-the-erlang-and-haskell-hype-for-servers

<http://www.codexon.com/posts/debunking-the-erlang-and-haskell-hype-for-servers>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 at 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 at avvanta.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100502/31d00768/attachment.html