On Thu, Nov 11, 2004 at 11:36:20AM -0800, John Gardiner Myers wrote:
> Dave Mitchell via RT wrote:
>
> >I havn't looked closely at this yet, but surely nulling PL_curpm will
> >cause $1 etc to get lost across win32 forks
> >
> Most likely. The alternative is to do a deep copy of the PMOP, possibly
> worrying about whether or not the last searched string was shared.
It should already be duplicated. PL_curpm simply points to the op
assoaited with the most recent successful match. In ithread builds, this
op has a targ value which is an index into PL_regex_pad. This contains an
array of ptrs to REGEXP structures. When an interpreter is cloned,
these structures are duped.
Since any strings referenced by this REGEXP are also duped, there
shouldn't (in theory) be any shared strings.
> There didn't seem much point to preserving $1 et al across
> threads::create().
But possibly more point in preserving across a win32 fork().
> Also, since the PMOP doesn't appear to be refcounted, I suspect it might
> be leaked upon a threads::join().
It souldn't be. It just points to a particular op within the current sub's
optree. When the last sub to refererence that optree is freed (typically
on thread exit), the whole optree is freed. By now (barring bugs),
PL_curpm shoulpdn't be pointing anywhere within that tree
> I did find it odd that there were two different functions for cloning an
> interpreter.
One is for the old 5.005 threads model.
--
The Enterprise is captured by a vastly superior alien intelligence which
does not put them on trial.
-- Things That Never Happen in "Star Trek" #10
