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