As I have migrated more of my application into Haskell, I find that I/O in one thread effectively blocks other threads. That's rather the opposite of what I need - I don't care so much if Haskell threads manage to compute in parallel, but the application should continue to function, in other threads, while an I/O has one thread blocked. Is that supposed to happen, is there anything I can do about it? Specifically I'm talking about OpenSSL SSL_read(). In this case, while a file descriptor is involved, there is also (I assume) some buffering, so it isn't a simple matter of deferring SSL_read() until data arrives at the fd. I'm hoping there's something more generic, that unblocks other threads during any foreign call - as one would do in Python, for example, bracking a foreign call with C macros that release and acquire the interpreter global lock. You'd also use this with functions like open(), which may not return immediately but don't answer to select(). All the Haskell code in question is executing in callbacks, from threads started in C++. The thread that actually does the network I/O could if necessary be started in 1st generation Haskell as a special case, if that might make any difference. I disable the RTS clock itimer signals, because something in the libraries I'm using doesn't thrive under a barrage of signals. (Environment setting GHCRTS=-V0.) The consequence, according to the documentation, should be "Context switches will still happen, but deterministically and at a rate much faster than normal", and anyway I suppose that's talking about green threads, not the OS threads where context switches are an OS function. Thanks! Donn Cave, donn@avvanta.com