Nigel Sandever <[EMAIL PROTECTED]> wrote: > On Sat, 3 Jan 2004 11:35:37 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote: >> That's exactly, what a ParrotInterpreter is: "the entire state for a >> thread".
> This is only true if a thread == interpreter. > If a single interpreter can run 2 threads then that single interpreter > cannot represent the state of both threads safely. Yep. So if a single interpreter (which is almost a thread state) should run two threads, you have to allocate and swap all. What should the advantage of such a solution be? > With 5005threads, multiple threads exist in a single interpreter. These are obsolete. > With ithreads, each thread is also a seperate interpreter. > Spawning a new thread becomes a process of duplicating everything. > The interpreter, the perl program, and all it existing data. Partly yes. A new interpreter is created, the program, i.e. the opcode stream is *not* duplicated, but JIT or prederef information has to be rebuilt (on demand, if that run-core is running), and existing non-shared data items are cloned. > Sharing data between the threads/interpreters is implemented by > tieing Parrot != perl5.ithreads > If Parrot has found a way of avoiding these costs and limitations > then everything I offered is a waste of time, because these are > the issues was attempting to address. I posted a very premature benchmark result, where an unoptimized Parrot build is 8 times faster then the equivalent perl5 code. > And the reaction from those wh have tried to make use of ithreads > under p5 are all too aware that replicating them for Parrot would > be ..... [phrase deleted as too emotionally charged:)] I don't know how ithreads are working internally WRT the relevant issues like object allocation and such. But threads at the OS level provide shared code and data segments. So at the VM level you have to unshare non-shared resources at thread creation. You can copy objects lazily and make 2 distinct items when writing, or you copy them in the first place. But you have these costs at thread start - and not later. > Nigel. leo
