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.