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

[John Lask]

As I said, it is very unix centric. The backend methods rely upon file 
descriptors which in the windows world are specific to the C rts. It is 
the backend that requires the abstraction from os specific 
structures/handling.

> 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
> 
>