haskell httpd

[Peter Simons]

Paul Graunke writes:

 > [...] event driven servers (which are supposedly oh so
 > much faster.)

At least in my experience, multiplexing servers _are_
significantly faster than those relying on the OS (or
whatever library) to do the scheduling. They also tend to be
much more efficient in terms of memory consumption, thus
allowing for more simultaneous connections than a fork()ing
or pthread_xxx()ing server would. (Not a big surprise, if
you think about it.)


 > I assume Peter meant cooperative threads where a
 > scheduler chooses the next bit-o-code to run rather than
 > coroutines where the yielder explicitly calls some other
 > coroutine.

Yes, you're right.

I like to think of it as "coroutines", because there _is_ a
call to "yield", even though it is hidden from the
programmer. (The monad switched contexts every time an I/O
primitive would block.) But cooperative multi-tasking is
probably the more fitting term.


 > Were the asynchronous IO primitives too ugly to deal with
 > cleanly, or was the performance gain too small to be
 > worth while?

It has been a mixture of both. To actually do asynchronous
I/O in Haskell, you'll need

    hGetBufNonBlocking :: Handle -> Ptr a -> Int -> IO Int
    hPutBufNonBlocking :: Handle -> Ptr a -> Int -> IO Int

which aren't available in any of the released GHC versions
yet. Thus, you'll have to use the most current GHC version
from CVS. Good luck. :-)

Aside from that, it appears to be impossible to combine
poll()-scheduled Haskell code with the "traditionally"
scheduled Haskell code in the same program -- unless you
count busy polling as a viable solution. GHC's new forkOS
function _might_ remedy this, but I have no first-hand
experience with it yet.

In the end, I had lots of pretty fast code, which compiled
only with an unstable development version of the compiler
and didn't mix with anybody else's code -- only to implement
something GHC's run-time system implemented already anyway.
So I gave up.

Peter