On Jan 3, 2006, at 2:30 PM, Simon Marlow wrote:
The default context switch interval in GHC is 0.02 seconds, measured in CPU time by default. GHC's scheduler is stricly round- robin, so therefore with 100 threads in the system it can be 2 seconds between a thread being descheduled and scheduled again.
I measured the time taken to unpickle those large 50k packets as 0.3 seconds on my amd64 box (program compiled *without* optimisation), so the thread can get descheduled twice during while unpickling a large packet, giving a >4s delay with 100 threads running.
Is it impractical then to implement this type of app in Haskell? Based on the nature of Haskell scheduling I would be inclined to say yes. I'm including information on the Erlang scheduler below. I think it's possible to emulate the workings of the Erlang scheduler in Haskell by using delimited continuations a-la Zipper File Server/ OS. A single delimited continuation (request in Zipper FS parlance?) would be a scheduling unit and a programmer could then tune the "scheduler" to their hearts content. Apart from putting a lot of burden on the programmer this becomes quite troublesome when multiple sockets or file descriptors are concerned. There's no easy way to plug into the select facility of the Haskell runtime to receive notifications of input available. You will notice the Zipper FS spending quite a few lines of code to roll its own select facility. The Erlang scheduler is based on reduction count where one reduction is roughly equivalent to a function call. See http://www.erlang.org/ ml-archive/erlang-questions/200104/msg00072.html for more detail. There's also this helpful bit of information: -- erlang:bump_reductions(Reductions) -> void() Types Reductions = int() This implementation-dependent function increments the reduction counter for the calling process. In the Beam emulator, the reduction counter is normally incremented by one for each func- tion and BIF call, and a context switch is forced when the counter reaches 1000. -- Regarding the issue of why a logger process in Erlang does not get overwhelved, this is the reply I got from Raimo Niskanen (Erlang team at Ericsson): There is a small fix in the scheduler for the standard producer/consumer problem: A process that sends to a receiver having a large receive queue gets punished with a large reduction (number of function calls) count for the send operation, and will therefore get smaller scheduling slots. Thanks, Joel -- http://wagerlabs.com/