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