Now, instead of using the RTS' select mechanism to wake up threads, we use a custom epoll handler. Using epoll-based event handling, and bytestring IO. The epoll approach will be replace GHC's select model soon ([http://github.com/tibbe/event/blob/master/src/System/Event/Thread.hs design here] showing how the concurrent Haskell primitives may be implemented in terms of epoll).

+

Now, instead of using the RTS' select mechanism to wake up threads, we use a custom epoll handler. Using epoll-based event handling, and bytestring IO. The epoll approach will replace GHC's select model soon ([http://github.com/tibbe/event/blob/master/src/System/Event/Thread.hs design here] showing how the concurrent Haskell primitives may be implemented in terms of epoll).

<haskell>

<haskell>

Revision as of 08:12, 18 January 2010

Some example of simple web server designs in Haskell, using preemptive concurrency, or event-driven approaches. Requirements:

Contents

Results

Basic concurrent server

Concurrent, with String IO. Here on each accept from the main thread, we create a new Handle, and forkIO a lightweight Haskell thread to write a string back to the client. Relies on the runtime scheduler to wake up the main thread in a timely fashion (i.e. via the current 'select' mechanism).

Concurrent, with network-bytestring

Now, using bytestring IO (via the network-bytestring package) (but still using the rts' select-based preemptive threads). Just means we allocate nothing in the body, and avoid a couple of copies to do the IO.

Epoll-based event callbacks

Now, instead of using the RTS' select mechanism to wake up threads, we use a custom epoll handler. Using epoll-based event handling, and bytestring IO. The epoll approach will replace GHC's select model soon (design here showing how the concurrent Haskell primitives may be implemented in terms of epoll).