On Mon, Apr 11, 2005 at 03:07:54PM +0200, Elizabeth Mattijsen wrote: > >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?
No. The called Perl code could in principle do almost anything: open files, create new threads, delete symbol tables etc; doing any of this in mid thread-creation is heading for disaster.
Ok, let's not do that then... ;-)
> >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 eachthread / interpreter had its own pool? Just goes to show how much I (don't) know about Perl's internals.
Well, win32 gives each thread its own malloc pool and complains bitterly if something is freed back into the wrong pool, but on top of that Perl uses arenas (bulk-allocated arrays of structures) for things like SVs, and each thread has its own set of arenas.
I'd forgotten about win32... ;-(
> >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 toget things working with threads, and the number of (wo)manyears already> spent on this worldwide, I wonder what is cheaper. At the moment I'm trying to address Stas's particular issue of cloned objects doing muliple DESTROYs (and multiple free()s if they have C structs attached). Since you're a real-live ithreads user
Well, I have done a lot of workarounds for threads, yes. I would not call me a live threads user, as I've basically given up on Perl ithreads for the production environments I was planning to use it for.
, I'm very interested to hear from you of any additional problems and/or possible workarounds, and see if I can incorporate them all into a unified solution. (With the proviso that you can't realistically call perl code during a cloning process. )
Additional problems, you say. Well, I've had to add specific code to DESTROY methods because they would get called without a proper object to work on at some points. Code like:
sub DESTROY {# Return now if we're in a rogue DESTROY
return unless UNIVERSAL::isa( $_[0],__PACKAGE__ ); #HACK
# other code
} #DESTROY
Unfortunately, not reproducible in any manner or form. And this may have been fixed already in later versions of (threaded) Perls.
(And with the other proviso that I'm not a language designer: Larry would come up with elegant solutions, while I would come up with hacky work-arounds).
Hacky would be perfectly acceptable for Perl 5 ithreads, in my opinion.
Liz
