At 9:10 PM -0800 11/17/02, Dave Whipp wrote:
Parrot's not just a VM--if we did our own threads that'd slow down JIT-generated code universally, or forbid the use of the JIT when running with threads, both of which are no good, not to mention all the fun we'd have recreating all the threading mistakes of the past. Plus we wouldn't be able to use multiple processors on systems that have them.Dan Sugalski wrote:The expensive part is the shared data. All the structures in an interpreter are too large to act on atomically without any sort of synchronization, so everything shared between interpreters needs to have a mutex associated with it. Mutex operations are generally cheap, but if you do enough of them they add up.Why do we need to use preemptive threads? If Parrot is a VM, then surely the threading can be implemented at its level, or even higher. If it is the VM that implements the threading, then its data structures don't need to be locked. The main problem with that approach is that the multithreading would not be able to preempt C-level callouts: but that could be solved by spawning a true thread only when code makes calls out of the parrot VM.
It's not easy to do right, and there's no real benefit to be had in doing it at all, so we're not. System threads are the way to go for us.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
