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 <[email protected]> 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, [email protected] > > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
