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

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 mailto:aran.donohue@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-serve...

http://www.codexon.com/posts/debunking-the-erlang-and-haskell-hype-for-serve...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