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

[Don Stewart]

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.donohue at gmail.com  
>> <mailto:aran.donohue at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe