Front page | perl.perl5.porters |
Postings from July 2010
On Thu, Jul 15, 2010 at 10:59:06AM +0100, Nicholas Clark wrote:
> On Wed, Jul 14, 2010 at 11:30:45PM +0100, Dave Mitchell wrote:
> > I've now pushed my work so far, to get it some smoky love.
> > The basic fixes are all in place: all of GvSTASH, SvSTASH and CvGV are now
> > always correctly handled (as far as I'm aware). There's one slight issue
> > with EGV still, and I have a number of bits of cleanup, optimisation and
> > documentation still to do.
>
> Woohoo!
>
> Definitely some level of optimisation desirable, as the correctness for
> CvGV() currently comes at the price of a MAGIC structure and an AV per
> subroutine in the symbol table.
>
> In theory that could all be abolished and replaced by a flag bit, as the GP of
> the GV that CvGV() points to is already pointing back to the PVCV ("we first
> thought of"). Except that that then relies on anyone assigning to CvGV()
> knowing to "do the right thing", which I believe now is cvgv_set(). But that
> can be enforced by changing
>
> #define CvGV(sv) ((XPVCV*)MUTABLE_PTR(SvANY(sv)))->xcv_gv
>
> to
>
> #define CvGV(sv) (((XPVCV*)MUTABLE_PTR(SvANY(sv)))->xcv_gv + 0)
>
> providing appropriate CvGV_set() macros in blead and ppport.h, and offering
> patches to whatever CPAN code needs updating as a result.
Ah, but its not that simple; its not just CvGV that needs protecting. For
example in the following:
sub f {}
my $r = \&f;
Dump $r;
*f = sub {};
&$r becomes 'orphaned'; its CvGV still points to *f, but *f's CV slot now
points elsewhere. So when *f is freed, it doesn't know to reset &$r's CvGV
field. This is why I decided to concentrate on getting a robust solution
working before trying to optimise.
The other thing I wanted to look into was, for backref magic, when there
is a single backref (that also happens not to be an AV), whether we could
stick it directly in mg_obj, saving the cost of an AV.
--
The crew of the Enterprise encounter an alien life form which is
surprisingly neither humanoid nor made from pure energy.
-- Things That Never Happen in "Star Trek" #22
Thread Previous
|
Thread Next