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
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?
Dumb question: are you compiling "-threaded"?
G
--
Gregory Collins
[I wrote initially, ...]
As I have migrated more of my application into Haskell, I find that I/O in one thread effectively blocks other threads.
Resolved - the SSL_read external I/O function needs to be "safe". My apologies for botching the mailing list threading, but I deleted the mail wherein someone helpfully asked whether I'd made my foreign calls "safe" or "unsafe", and I can't see that message on the archives. My initial take was, yes, of course I make external calls "safe", because they sure are going to trigger callbacks into the Haskell runtime and the documentation is quite clear about that. However, I'd made SSL_read "unsafe", since no callbacks there. Reversed that, and now my threads execute concurrently - SSL_read doesn't block Haskell execution in all the other threads. Either way, I can also report that it doesn't seem to matter whether SSL_read was called from a callback, or not. If unsafe, it blocks all the other threads either way, and if safe, it doesn't block them either way. So, thanks a lot, whoever you were! Henceforth I will play it safe and eschew unsafeness. I vaguely recall a discussion here a ways back, wherein the terms "safe" and "unsafe" were lamented and various confusing propositions were bandied about. I should dig that up if I can, and see if this practical example sheds some light on any of it. Donn Cave, donn@avvanta.com
participants (2)
-
Donn Cave -
Gregory Collins