[Haskell-cafe] concurrency vs. I/O in GHC

[Donn Cave]

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 at avvanta.com