Native Threads in the RTS

[Simon Marlow]

> | 2. Calling from foreign code into Haskell to a bound foreign import
> will
> | require some special handling to ensure that a subsequent=20
> call out to
> | foreign code will use the same native thread.  Why couldn't this
> special
> | handling select the same Haskell thread instead of creating=20
> a new one?
>=20
> This is just an efficiency issue, right?   If creating a=20
> Haskell thread
> from scratch is very cheap, then it's easier to do that each=20
> time rather
> than to try to find the carcass of a completed Haskell=20
> thread.   If you
> do the latter, you need to get into carcass management. =20
>=20
> But maybe there is more to it than efficiency in your mind?

To recap, the suggestion was that a Haskell thread which makes a foreign
call, which is turn calls back into Haskell, should use the same Haskell
thread for the callback.  So the Haskell thread is not a carcass, it is
still running, but blocked waiting for the result of the foreign call.

I'm not sure I've quite got my head around all the implications of doing
this, but it sounds possible.  However, I'm not completely convinced
it's desirable: the gain seems to be in efficiency only, and a fairly
small one (creating threads is quite cheap).  I imagine you could
demonstrate a performance gain by doing this for an application which
does a lot of callbacks, though.

The current situation has the advantage of simplicity:=20

  * for each 'foreign export' we create a single Haskell thread which
    lives until completion of the IO action.  We can consider a
standalone
    program as a call to 'foreign export main :: IO a' from a simple C
    wrapper (in fact, that's almost exactly how it works).

Cheers,
	Simon