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

[Johan Tibell]

On Sun, May 2, 2010 at 8:45 PM, Aran Donohue <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100502/3a9c01c0/attachment.html