Native Threads in the RTS

Simon Peyton-Jones simonpj@microsoft.com
Wed, 20 Nov 2002 08:50:50 -0000


| I've now written up a slightly more formal proposal for native
threads.
| (OK, it's only a tiny bit more formal...)
| I doubt I have explained everything clearly, please tell me which
| points are unclear. And of course please tell me what you like/don't
| like about it.

Great, thanks.  I hope you'll keep it up to date so that by the time the
discussion converges it can serve as a specification and rationale.  We
can put it in CVS too... Simon will think of where! Ultimately it'd be
worth integrating with
http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/multi-thread.
html

Simon


| A "native" haskell thread and all foreign imported functions that it
| calls are executed in its associated OS thread.

This part is ok

| A foreign exported
| callback that is called from C code executing in that OS thread is
| executed in the native haskell thread.

This is the bit I don't understand.   Is the only scenario you have in
mind here

	native Haskell thread
	calls C
	which calls Haskell

and you want all that in the same native thread?

What about this?

	native Haskell thread
	calls C
	which installs a pointer to a foreign-exported Haskell function
		 in some C data structure

Later... some other Haskell thread
	calls C
	which waits for an event
	which calls the callback

So the callback was installed by a native thread, but won't be executed
by it.  Is that ok?  Anyway I think it would be worth explaining what is
guaranteed a bit more clearly.

| If a "green" haskell thread enters a foreign imported function marked
| as "safe", all other green threads are blocked. Native haskell threads
| continue to run in their own OS threads.=20

No, I don't think so.  The reason that 'safe' is cheaper than
'threadsafe' is that the current worker OS thread does not need to
release the Big Lock it holds on the Haskell heap, thereby allowing
other green threads to run.   Instead, it holds the lock, executes the
call, and returns.  At least I think this is the idea, but it's all
jolly slippery.

| Other things I'm not sure about:

Presumably if a native thread spawns a thread using forkIO, it gets just
a green thread?  If it used forkNativeThread it gets a distinct native
thread.  Better say this.