On Mon, Apr 11, 2005 at 03:07:54PM +0200, Elizabeth Mattijsen wrote:
> I _can_ take no for an answer, but want to make sure that we're
> dismissing this for the right reasons.
fair enough:-)
> >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.
> >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.
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.
> >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.
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, 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. )
(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).
--
The Enterprise's efficient long-range scanners detect a temporal vortex
distortion in good time, allowing it to be safely avoided via a minor
course correction.
-- Things That Never Happen in "Star Trek" #21
