"Simon Marlow"
Is it important which thread executes Haskell code (I bet no) and unsafe foreign calls (I don't know)? If not, couldn't the same OS thread execute code of both threads until a safe foreign call is made?
Actually in a bound thread, *all* foreign calls must be made using the correct OS thread, not just the safe ones. So your scheme would involve a context switch at every foreign call, which would end up being rather expensive.
Ok. As I understand this (and as I'm trying to implement a similar scheme for my language), when an unbound thread performs a safe C call, the current OS thread transforms from a worker to a bound thread, and another worker is spawn if needed for remaining Haskell threads. So I have another idea: Why is the main thread bound? Wouldn't it be sufficient that, in cases where it's important to have the main Haskell thread bound to the main OS thread, the programmer wraps the main computation in a function which calls C and then calls back Haskell? Such function, if executed before spawning other threads which perform safe C calls, would in effect bind the threads together. That way there would be no OS thread synchronization needed when the main Haskell thread synchronizes with unbound threads. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/