On Sat, Jan 03, 2004 at 08:05:13PM +0100, Elizabeth Mattijsen wrote: > Actually, you can bless a reference to a shared variable, but youcan't share a blessed object (the sharing will let you lose the content of the object). I think shared compound data structures _are_ possible, but very tricky to get right (because the CLONE sub is called as a package method, rather than as an object method: see> Thread::Bless for an attempt at getting around this). Nested shared structures work just fine, and there's no need to mess with CLONE for plain data.
Indeed. But as soon as there is something special such as a datastructure external to Perl between threads (which happens automatically "shared" automatically, because Perl doesn't know about the datastructure, so the cloned objects point to the same memory address), then you're in trouble. Simply because you now have multiple DESTROYs called on the same external data-structure. If the function of the DESTROY is to free the memory of the external data-structure, you're in trouble as soon as the first thread is done. ;-(
> >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:)] It's the implementation of ithreads in p5 that sucks, not the concept itself. The use of COW makes new thread creation cheap, and the use of lock PMCs interposed on the real PMCs makes shareing easy.
I agree that Perl ithreads as *a* concept are ok.
The same could be said about what are now referred to as 5.005 threads. Ok as *a* concept. And closer to what many non-Perl people consider to be "threads".
Pardon my French, but both suck in the implementation. And it is not for lack of effort by the people who developed it. It is for lack of a good foundation to build on. And we're talking foundation here now, we all want to make sure it is the best, earth-quake proofed, rocking foundation we can get!
Liz
