develooper Front page | perl.perl5.porters | Postings from September 2010

[PATCH] Re: [perl #77548] Runtime hinthash from XS

Thread Previous | Thread Next
Ben Morrow
September 4, 2010 08:08
[PATCH] Re: [perl #77548] Runtime hinthash from XS
Message ID:
Quoth (Ben Morrow):
> Quoth (Florian Ragwitz):
> > 
> > I'm not fully happy with the naming.
> > 
> > All other hints-related code in the core I've seen so far refers to the
> > hints hash as "hints", not "hinthash". Also a function called
> > hinthash_2hv not actually taking a hinthash but returning the hinthash
> > as an HV seems slightly off.
> > 
> > cop_fetch_hint_hv/cop_fetch_hint_{x,sv,pvn,pvs}, maybe?
> I agree, though I think I prefer cop_hints_fetch(sv|pv[ns]) and
> cop_hints_2hv. I think the '2hv' is important, because it isn't
> returning the actual hinthash but rather a copy of it.

OK, I've done up a new patch with these names.

> > Also, have you had a look at Devel::Caller's upcontext function? It was
> > originally based on the code you factored out into caller_cx, but is now
> > rather different. I'm curious if the new caller_cx function provides
> > everything that'd be needed to have Devel::Caller run on it.
> > 
> > There's also many more caller() implementation in xs, but they all seem
> > to be cargo-culted from Devel::Caller, so I guess it'd be nice if at
> > least that one was possible to be ported to caller_cx.
> I haven't (or, at least, not recently, so I can't remember the details).
> I did look at PadWalker, and AFAICT caller_cx is *not* sufficient for
> that, but I wasn't entirely following what was going on there.

OK, I've now looked at all this more carefully. Devel::Caller no longer
has its own implementation, but uses PadWalker's. This differs from
caller_cx in two ways:

    - It always returns the frame for the actual sub, rather than going
      up an extra frame if this sub was called from &DB::sub. This means
      that D::C and PW would need to use the dbcxp parameter rather than
      the return value.

    - It returns some other information about which callstack the frame
      was found in, and where we started and finished looking. PW seems
      to be using this to go grovelling around looking for evals: I
      don't quite see what this accomplishes, but I suspect it's left
      over from the days when evals weren't properly lexically scoped.
      D::C doesn't use those parameters at all (the
      PadWalker::_upcontext XSUB, rather than the C function behind it,
      doesn't support them anyway).

So yes, I believe D::C (and almost certainly PadWalker) could be
rewritten to use caller_cx (though PadWalker would need to use its own
stack-chasing logic on perls before 5.10, even if caller_cx was
available through ppport.h). I haven't tested this, though.


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