Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote: > 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,
Why is it shared automatically? Do you have an example for that? But anyway an interesting problem, I didn't consider until yet - thanks :) > ... 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. ;-( 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. [ perl5 thread concepts ] > Pardon my French, but both suck in the implementation. And it is not > for lack of effort by the people who developed it. The problem for sure was, to put threads on top of a working interpreter and a commonly used language. Parrots design is based on having threads, events, async IO in mind. It was surprisingly simple to implement these first steps that are running now. Separating the HLL layer from the engine probably helps a lot for such rather major design changes. > now, we all want to make sure it is the best, earth-quake proofed, > rocking foundation we can get! Yep. So again, your input is very welcome, > Liz leo
