Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote: > Indeed. But as soon as there is something special such as adatastructure external to Perl between threads (which happens automatically "shared" automatically, because Perl doesn't know about> the datastructure, Why is it shared automatically? Do you have an example for that?
When you use an external library in Perl, such as e.g. libxml, you have Perl data-structures and libxml data-structures. The Perl data-structures contain pointers to the libxml data-structures.
In comes the starting of an ithread and Perl clones all of the Perl data-structures. But it copies _only_ does things it knows about. And thus leaves the pointers to the libxml data-structures untouched. Now you have 2 Perl data-structures that point to the _same_ libxml data-structures. Voila, instant sharing.
With disastrous results. Because as soon as the thread ends, the cloned Perl object in the thread goes out of scope. Perl then calls the DESTROY method on the object, which then frees up the libxml data-structures. That's what it's supposed to do. Meanwhile, back in the original thread, the pointers in the Perl object now point at freed memory, rather than a live libxml data-structure. And chaos ensues sooner or later. Of course, chaos could well ensue before the thread is ended, because both threads think they have exclusive access to the libxml data-structure.
Hope this explanation made sense.
> ... so the cloned objects point to the same memoryaddress), 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. ;-( Maybe that DOD/GC can help here. A shared object can and will be destroyed only, when the last holder of that object has released it.
But do you see now how complicated this can become if thread === interpreter?
Liz
