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, ())) prodServiceThread 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.