develooper Front page | perl.perl5.porters | Postings from October 2014

Re: Shared padlists

Thread Previous | Thread Next
Father Chrysostomos
October 28, 2014 19:52
Re: Shared padlists
Message ID:
I wrote:
> Dave Mitchell asked:
> > Also, is a boolean flag in the pad sufficient, or would you need a
> > counter, to handle recursion? Perhaps CvDEPTH should just be moved into
> > the pad?
> I thought of the latter at first, but the sub would need to know
> whether the CvDEPTH applies to it.  So I thought of putting CvDEPTH in
> both, but realised that one copy of it only needed to be a boolean.  A
> new flag in CvFLAGS would also work.

Wait.  I'm not thinking straight.

According to what I was thinking before, a boolean would be suffi-
cient, because you just have to check if some other sub is using the
padlist already to decide whether to clone the whole thing.

But I've been stuck mentally associating CvDEPTH with the CV itself.

If CvDEPTH goes inside the padlist, then it may not be necessary for a
sub to clone a padlist that is already active.  Given two subrefs $a
and $b that come from the same closure prototype, $a->() will use pad
1, and if it calls $b, $b will use pad 2, because it will already have
a depth of 1, even though it is not being called.

Any subs containing state vars or flip-flops (which have a scope simi-
lar to state vars) would be exempt from this optimisation.

We would have to change the logic surrounding 'Can't undef active

If we croak only if the padlist is about to be freed, then that
changes the behaviour of:

eval { undef &$a };
undef &$b;

inside a call to $a.  Formerly it would refuse to undefine &$a and
proceed to undefine &$b.  Now it would successfully undefine &$a and
croak when undefining &$b.

How much code would that break?  Close to zero, I hope.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About