On Thu, 2008-11-27 at 11:38 -0500, Brandon S. Allbery KF8NH wrote:
On 2008 Nov 27, at 8:51, Simon Marlow wrote:
No, the issue is that without real OS threads, a foreign call can't be pre-empted (pretty obvious when you think about it). waitForProcess ends up making a blocking foreign call - non-obvious, but at least it's documented.
The way this is usually handled in the non-threaded case is to either use SIGCHLD or non-blocking waitpid() so that "green" threads can continue running. I'm a little surprised this wasn't done.
Yes, we've discussed this in detail a few months back. We even have a partial implementation. However it stalled on needing a better signals API which we have not managed to get through the standardisation process. Unfortunately there is no non-blocking (non-polling) waitpid() and the global (process-scope) nature of signals is a pain. Duncan