On Mon, Apr 11, 2005 at 01:54:57PM +0200, Elizabeth Mattijsen wrote:Hmmm... wouldn't it be handier to have a method CLONED() which is called for each object (and with the object as parameter) and which is expected to return a cloned objects, ready to be used inside the thread? If it returns undef, then the object should not be cloned. If it return an object, then that object should be used inside the> thread. No :-(
I _can_ take no for an answer, but want to make sure that we're dismissing this for the right reasons.
a) Perl-level functions can't be called during the middle of cloning, as the internal state isn't yet consistent.
I guess some putting these objects to be vivified inside the thread, into some lexical scope voodoo for which the new interpreter, although not yet stable, is keeping the only reference, wouldn't be an option?
b) Cloning of objects can't be done at the Perl level, it has to be done at the C level, eg making sure that memory is allocated from the correct pool.
Ok, I see that that would be a problem. I hadn't realised that each thread / interpreter had its own pool? Just goes to show how much I (don't) know about Perl's internals.
c) It would be very expensive to call a Perl function for each object
True. But considering the hoops a developer would have to go through to get things working with threads, and the number of (wo)manyears already spent on this worldwide, I wonder what is cheaper.
Liz
