The event library has a pluggable interface, with multiple backends, and is entirely portable as a result. You just swap in your 'select' mechanism:
http://github.com/tibbe/event/blob/master/src/System/Event/EPoll.hsc http://github.com/tibbe/event/blob/master/src/System/Event/Poll.hsc http://github.com/tibbe/event/blob/master/src/System/Event/KQueue.hsc Now, if you can implement the Backend methods, http://github.com/tibbe/event/blob/master/src/System/Event/Internal.hs You'll be good to go -- and we already know GHC can do threads on Windows, so the same mechanism should work faily easily. jvlask: > Re event library and merge into haskell base: has any thought gone into > the "windows" version of the library. Last I looked it was very unix > centric - the windows api is very different. I believe it will require > major rework to abstract the commonalities and deal efficiently with the > differences. > > I suspect any talk of a merge is premature. > >> On Sun, May 2, 2010 at 8:45 PM, Aran Donohue <aran.dono...@gmail.com >> <mailto:aran.dono...@gmail.com>> wrote: >> >> 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. >> >> >> The Haskell Network.Socket module uses Strings to represent binary >> data. This is wrong as String is an abstract data type representing a >> sequence of Unicode code points, not bytes. Arguably the Network.Socket >> module should have used [Word8] instead of String. However, String and >> [Word8] are both represented as linked lists which is not a very >> efficient representation for large blocks of binary data. bytestring is >> simply a more efficient encoding of [Word8] and should be use anywhere >> you want to represent binary data. >> >> It's too late to change Network.Socket to use ByteStrings instead of >> Strings as it would break too much code. I wrote network-bytestring so >> that you can use ByteStrings instead of Strings when doing socket I/O. >> The network-bytestring package will most likely be merged into the >> network package at some point. >> >> While you can use the event library explicitly this is not how we >> intended the majority of users to use it. The goal is to integrate it >> into GHC 6.14 and as replace the current I/O manager. That means that >> you will be able to write standard forkIO based code (like in the >> linked article) and expect around 20,000 requests/second on one core >> (depending on your hardware). >> >> >> 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. >> >> >> If we reach our GHC 6.14 goal you will. >> >> Cheers, >> Johan >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe