[Haskell-cafe] STM, IO and event loops

Joel Reymont joelr1 at gmail.com
Mon Nov 28 05:30:01 EST 2005

This is exactly what I do. I use hGetBuf with a timeout. I do not  
compile with -threaded, should I? Does it change anything?

Also, is there a way to somehow stick all the sockets that I read  
from into a select to monitor input on any of them and wake up a  
thread once input becomes available? I do not need to be cross- 
platform here and would be fine so long as it works on Unix.

I understand there is threadWaitRead :: Fd -> IO (). Would it do the  
trick for me? Would it do it in a cross-platform fashion?

The function is broken on MingGW as per Conc.lhs, is GHC for Windows  
always compiled under MinGW?

Otherwise threadWaitRead is defined like this:

waitForReadEvent :: Fd -> IO ()
waitForReadEvent fd = do
   m <- newEmptyMVar
   atomicModifyIORef pendingEvents (\xs -> (Read fd m : xs, ()))
   takeMVar m

and I also see this:

buildFdSets maxfd readfds writefds [] = return maxfd
buildFdSets maxfd readfds writefds (Read fd m : reqs) = do
   fdSet fd readfds
   buildFdSets (max maxfd fd) readfds writefds reqs
buildFdSets maxfd readfds writefds (Write fd m : reqs) = do
   fdSet fd writefds
   buildFdSets (max maxfd fd) readfds writefds reqs

This tells me that calling threadWaitRead is the way to go since it  
seems like it will add the fd to select () or some such on non- 
Windows platforms. Am I right and what happens on Windows then?

	Thanks, Joel

On Nov 28, 2005, at 8:57 AM, Simon Peyton-Jones wrote:

> 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.


More information about the Haskell-Cafe mailing list