On Mar 3, 2006, at 5:29 AM, Thomas Shackell wrote:
That is very good to hear. It seems to me that the two biggest
issues are:
-- supporting multiple execution stacks
-- blocking I/O and FFI calls
How did you decide to handle these problems (mostly for my
curiousity)?
You're quite right, those were two of the biggest issues :-)
The first thing to note is that concurrency is implemented in Yhc
by the interpretter running some instructions for one process, then
some more instructions for the next process and so on.
This is rather than using one OS thread per Haskell process because
all processes can access the global heap, so if using OS threads it
would be necessary to either lock every heap access (incredibly
slow) or use some of the truely nasty tricks that concurrent GHC uses.
The first problem, as you note, is that originally we only had one
stack but now every process needs its own stack. After considering
possible options I decided the easiest way was:
- process stacks become normal nodes in the heap, and are garbage
collected like other heap nodes. This preserves the property that
we can't run out of heap but not stack (and vice versa).
[snip]
How do you detect when a process runs out of stack? Do you calculate
the max stack usage from the bytecode and check before you push a new
stack frame?
Now going back, the approach of running some instructions from one
thread then some more from another is fine providing every
instruction runs quickly. They all do, with one exception,
PRIMITIVE. This is because PRIMITIVE is used for IO actions/FFI calls.
The solution? Well the basic idea is "just spawn an OS thread to do
the IO action while the main thread continues running Haskell".
[snip]
How do you deal with OS threads portably? I assume you use pthreads
for *nix. Does windows know pthreads or did you create some thin
wrapper over OS specific threading?
Hope that answers your questions :-)
Yes, thank you!
Rob Dockins
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
-- TMBG
_______________________________________________
Yhc mailing list
[email protected]
http://haskell.org/mailman/listinfo/yhc
