Native Threads in the RTS

[Simon Marlow]

> Or, we can adopt a much weaker semantics than Wolfgang=20
> intended and have:
>=20
>     $0 <=3D bindees(f) - uses(f)$
>=20
> 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:
>=20
> 1) That foreign threads are _not_ used to execute Haskell code.
>=20
> 2) That we maintain a lock on foreign threads so that only one
>    Haskell thread tries to use it at a time.
>=20
> I see two potential problems with this (but would like to hear which,
> if either, dominates your thoughts):
>=20
> 1) If foreign threads cannot be used to execute Haskell code, foreign
>    calls require (OS-level) context switches which are expensive.
>=20
> 2) Adding an implicit lock to foreign calls might surprise=20
> 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