Parrot's threading model

Okay, I think a quick sketch of the current plan's in order, since I'm 
about to start implementing it. :)

Parrot's going with the "one thread per interpreter" model of threading. 
That makes a lot of things safer, since we reduce the amount of stuff 
shared between interpreters, and don't try running multiple threads within 
the same interpreter. (Been there, did that, *not* doing it again...)

Raw bytecode *will* be shareable between interpreters, but this is OK as 
bytecode is readonly. (As opposed to the fixup sections and suchlike 
things, which need to get cloned rather than shared)

PMCs will be shareable, but only when explicitly marked as shared. Passing 
an unshared PMC to another interpreter's a fatal error. PMCs *can* be 
cloned when an interpreter is created, and they may also have their 
contents be copied into a PMC for another interpreter at specific 
coordination points. You may *not* put an unshared PMC into a shared container.

Interpreters may be started with custom dispatch tables, or in the Safe 
interpreter compartment. Safe interpreters impose resource limits, check 
boundaries for jumps and branches, and may restrict what operations can be 
performed.

Interpreters are *not* obligated to be clones of existing interpreters. 
It's perfectly acceptable to start up a new interpreter that's completely 
empty and goes from scratch.

PMCs that are shared between interpreters are responsible for maintaining 
their own internal integrity. To this end, every vtable has a shadow 
"shared" vtable. When a PMC is shared, a mutex is created for it and the 
shadow vtable is switched in. The functions in this vtable should lock and 
unlock the PMC's mutex as need be to maintain its internal integrity. (If 
that's even necessary--PMC types that use only the integer cache portion of 
the PMC header might not need to, for example)

An interpreter can get access to a shared PMC in another interpreter only 
at interpreter clone time, or if explicitly passed in via an (as yet 
undetermined) handoff method.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

• Parrot's threading model by Dan Sugalski
• Re: Parrot's threading model by Dan Sugalski
• Shared objects and handoffs (was Re: Parrot's threading model) by David M. Lloyd
• Re: Parrot's threading model by David M. Lloyd