"Simon Marlow" <[EMAIL PROTECTED]> writes:
>> 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
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
