> Or, we can adopt a much weaker semantics than Wolfgang
> intended and have:
>
> $0 <= bindees(f) - uses(f)$
>
> This would allow several currently running, active Haskell threads to
> all be bound to the same foreign thread. When any of these threads
> makes a foreign call, the other threads could all keep running and
> they would only block if they too tried to make foreign calls. From
> an implementation point of view, this requires:
>
> 1) That foreign threads are _not_ used to execute Haskell code.
>
> 2) That we maintain a lock on foreign threads so that only one
> Haskell thread tries to use it at a time.
>
> I see two potential problems with this (but would like to hear which,
> if either, dominates your thoughts):
>
> 1) If foreign threads cannot be used to execute Haskell code, foreign
> calls require (OS-level) context switches which are expensive.
>
> 2) Adding an implicit lock to foreign calls might surprise
> programmers.
Another problem, from an implementation point of view, is that we would
have to surround "unsafe" foreign calls with a lot of context-switching
gumph, in case the calling Haskell thread is bound to a native thread.
I really think we don't want to do this.
The "thread groups" idea is similar, but only allows one of the Haskell
threads in a group to be executing at any one time. This means you can
run the Haskell thread using its native thread, and you don't have to
context switch on every C call. However, I believe it would be tricky
to implement this correctly in the scheduler (not impossible, just
tricky and hard to test).
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
