Jeff Clites <[EMAIL PROTECTED]> wrote: > On Jan 3, 2004, at 5:24 PM, Matt Fowles wrote:
>> Why must each thread have its own interpreter? > The short answer is that the bulk of the state of the virtual machine > (including, and most importantly, its registers and register stacks) > needs to be per-thread, since it represents the "execution context" > which is logically thread-local. Yep. A struct Parrot_Interp has all the information to run one thread of execution. When you start a new VM thread, you need a new Parrot_Interp to run the code. But it depends on the thread type how this new Parrot_Interp is created. The range is from all is new except the opcode stream (type 1 - nothing shared thread) to only register + stacks + some more is distinct for type 4 - the shared everything case. Perl5 doesn't have a real interpreter structure, its mainly a bunch of globals. But when compiled with threads enabled tons of macros convert these to the thread context, which is then passed around as first argument of API calls - mostly (that's at least how I understand the src). This thread context is our interpreter structure with all the necessary information or state to run a piece of code as the only one or as a distinct thread. > That said, I do think we have a terminology problem, ... > ... It would be clearer to say that we > have two "threads" in one "interpreter", and just note that almost all > of our state lives in the "thread" structure. (That would mean that the > thing which is being passed into all of our API would be called the > thread, not the interpreter, Yep. But the thing passed around happens to be named interpreter, so that's our thread state, if you run single-threaded or not doesn't matter. A thread-enabled interpreter is created by filling one additional structure "thread_data" with thread-specific items like thread handle or thread ID. But anyway the state is called interpreter. > JEff leo
