Native Threads in the RTS

[Alastair Reid]

> This is all getting highly confusing, as it seems we're working with
> different ideas of what's on the table.  Alastair: you seem to be
> working on your own proposal - could you write it down either as a
> complete proposal or diffs to Wolfgangs?

I did.  You sent comments on it and I sent back a cleaned up version.
Here it is again.

--
Alastair


Goals
~~~~~

Since foreign libraries sometimes exploit thread local state, it is
necessary to provide some control over which thread is used to execute
foreign code.  In particular, it is important that it should be
possible for Haskell code to arrange that a sequence of calls to a
given library are performed by the same foreign (or 'native') thread
and that if an external library calls into Haskell, then any outgoing
calls from Haskell are performed by the same foreign thread.

This specification is intended to be implementable both by
multi-threaded Haskell implementations and by single-threaded
implementations and so it does not comment on which particular OS
thread is used to execute Haskell code.


Design
~~~~~~

Haskell threads may be bound with either zero or one foreign threads.
Binding occurs at thread creation time.  There are four ways to
create Haskell threads so there are four cases to consider:

1) forkForeignThread :: IO () -> IO ThreadId
   The fresh Haskell thread is bound to a fresh foreign thread.

2) forkIO :: IO () -> IO ThreadId
   The fresh Haskell thread is not bound to a foreign thread.

3) Calls to a bound foreign export allocate a fresh Haskell
   thread which is then bound to the calling thread thread.

   Bound foreign exports have the form

     foreign export bound foo :: <type>

   and otherwise behave like normal foreign exports.

4) ToDo: For completeness, there ought to be a way to 'bind'
   finalizers to foreign threads but no concrete proposal currently
   exists.

Calls to bound foreign imports by Haskell threads which are bound to a
foreign thread are performed by that foreign thread.

   Bound foreign imports have the form

     foreign import bound foo :: <type>

   and otherwise behave like normal foreign imports.

Calls to any free (i.e., not bound) foreign imports may be made in
the bound thread (if it exists) or by some other foreign thread at
the implementation's discretion.


Issues
~~~~~~

The notion of bound foreign imports could be eliminated by saying that
all foreign calls are performed by the bound thread if one exists and
eliminate the concept of 'bound foreign imports'.  The only reason to
allow any flexibility is to allow for faster implementations which
perform less context switching - this is especially important for
'unsafe' foreign calls.


An alternative to forkForeignThread is to allow direct control over
thread binding:

   bindThread :: ForeignThread -> IO ()
   The current Haskell thread is bound to a fresh foreign thread.
   (Any previous binding is forgotten.)

This leads to a much simpler design since it eliminates the need for
forkForeignThread and can be used for finalizers too.  The cost is
that every bound foreign call requires locking and a context switch
since multiple Haskell threads may be bound to the same foreign thread
and could try to make a foreign call 'at the same time'.  Binding
finalizers to foreign threads also seems to require locking and a
context switch for the same reason.