[Haskell-cafe] STM, IO and event loops

Simon Marlow simonmar at microsoft.com
Mon Nov 28 06:32:44 EST 2005


On Unix with -threaded, all blocking I/O using Handles or sockets goes
via the I/O manager thread, which multiplexes all the blocked I/O
requests into a single select() call.  If you have 20k blocked socket
reads, there will be 20k lightweight Haskell threads, and probably 2 or
3 real OS threads.  Without -threaded the outcome is pretty much the
same, except the runtime does the select().

On Windows, unfortunately you'll get 20k OS threads for this scenario
(regardless of -threaded), because we haven't implemented the I/O
manager on Windows yet.

So, to answer the question:

>> Are there any facilities in Haskell that can poll a set of 10k
>> descriptors and retrieve input from the first available?

Yes, you have one forkIO thread per descriptor, and you do your I/O
using standard Handle I/O or Network.Socket.recvfrom/sendto.
Unfortunately it'll be expensive on Windows right now, but the best way
to fix this would be to implement the I/O manager (in GHC.Conc) rather
than doing the multiplexing explicitly in your app code.

Cheers,
	Simon

On 28 November 2005 08:57, Simon Peyton-Jones wrote:

> A good design pattern, I think, is to have a Haskell thread dedicated
> to each socket.  It can suck on the socket and dump what it finds
> into an STM channel or buffer.  Then other threads (the ones doing
> the work) can read it transactionally.
> 
> It should be find to have lots of threads, esp if most of them are
> asleep.  The only thing to watch out for is that GHC's runtime system
> will consume one *OS* thread for each *blocked* foreign call.  So if
> you have 10k threads each making a separate call to the OS to read
> from 10k sockets, and they all block, you'll use 10k OS threads, and
> that will probably fail.
> 
> Simon
> 
>> -----Original Message-----
>> From: haskell-cafe-bounces at haskell.org
> [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Joel
>> Reymont
>> Sent: 27 November 2005 11:12
>> To: Haskell Cafe
>> Subject: [Haskell-cafe] STM, IO and event loops
>> 
>> Folks,
>> 
>> I'm trying to build an event-driven system that includes multiple
>> event channels. I would have one channel for network events and
>> another one for events sent by other threads. I would like to use STM
>> and `orElse` to poll the various event channels.
>> 
>> Is there a reasonably safe way to do this with STM and IO?
>> 
>> The network side of things currently times out after a given number
>> of seconds if no input is available but can also throw exceptions.
>> I'm having a hard time figuring out how to wrap this in STM.
>> 
>> There's another alternative that I can think of...
>> 
>> My poker bots are launched in separate threads but do not talk to
>> each other right now. They just receive events from the network. I
>> would like a poker bot to tell others to stop playing and exit, for
>> example. I guess I could build poker bots with an event loop that
>> reads from a TChan but... I would then need twice as many threads
>> since each bot has a socket associated with it and one thread per bot
>> would need to read from the socket and push events into the TChan.
>> 
>> Are there any facilities in Haskell that can poll a set of 10k
>> descriptors and retrieve input from the first available?
>> 
>> I don't know if I should be concerned with launching 20k threads vs.
>> 10k threads but it seems that disassociating bots from the network
>> has some positive effects. I could compose packets by hand in the
>> interpreter and feed them to the TChan by hand to test individual
>> bots, for example. 
>> 
>> Any advice is appreciated!
>> 
>> 	Thanks, Joel
>> 
>> --
>> http://wagerlabs.com/
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



More information about the Haskell-Cafe mailing list