> 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