Nigel Sandever <[EMAIL PROTECTED]> wrote: [ Line length adjusted for readability ]
> VIRTUAL MACHINE INTERPRETER > At any given point in the running of the interpreter, the VM register > set, program counter and stack must represent the entire state for > that thread. That's exactly, what a ParrotInterpreter is: "the entire state for a thread". > I am completely against the idea of VM threads having a 1:1 > relationship with interpreters. While these can be separated its not efficient. Please note that Parrot is a register-based VM. Switching state is *not* switching a stack-pointer and a PC thingy like in stack-based VMs. > ... The runtime costs of duplicating all > shared data between interpreters, tying all shared variables, added to > the cost of locking, throw away almost all of the benefit of using > threads. No, shared resources are not duplicated, nor tied. The locking of course remains, but that's it. > The distinction is that a critical section does not disable time > slicing/ preemption. It prevents any thread attempting to enter an > owned critical section from receiving a timeslice until the current > owner relinquishes it. These are platform specific details. We will use whatever the platform/OS provides. In the source code its a LOCK() UNLOCK() pair. The LOCK() can be any atomic operation and doesn't need to call the kernel, if the lock is aquired. [ Lot of Wintel stuff snipped ] > Nigel Sandever. leo
