At 5:31 PM -0800 12/21/03, Jeff Clites wrote:It sounds like an assumption here is that separate threads get separate interpreter instances. I would have thought that a typical multithreaded program would have one interpreter instance and multiple threads (sharing that instance). I would think of separate interpreter instances as the analog of separate independent processes (at the Unix level), and that threads would be something more lightweight than that. There would be _some_ structure which is per-thread, but not logically the whole interpreter.
Been there, done that, got the scars to prove it. Doesn't work well in a system with guarantees of internal consistency and core data elements that are too large for atomic access by the processor. (And, while you can lock things, it gets really, really, *really* slow...)
1) It seems like you've made a leap here. I don't see how the need to guarantee the internal consistency of things such as strings directly implies per-thread allocation pools or file-descriptor tables. Having non-shared HLL-accessible data doesn't imply non-shared internal data structures.
2) Separate issue really, but: How can a language such as Java, which doesn't have inter-thread data-access restrictions, be implemented on top of Parrot?
JEff
