Re: APR::Table each() support for multivalued keys

Stas Bekman <stas@xxxxxxxxxx> writes:

> Joe Schaefer wrote:

[...]

> > :-) Not for this in mp2.  Technically the problem lies with
> > Perl_sv_setsv_flags, which does not copy magic (except for vstrings in
> > 5.8.1+, which explains the current apreq2 code).  Once I better
> > understand the purpose of the (currently undocumented?) mg_copy slot in
> > struct mgvtbl, I'll see if I can convince p5p to let Perl_sv_setsv_flags
> > copy magic whenever that slot is occupied.
> 
> That may just work, if it doesn't incur a significant delay for the
> generic case.

Heh, I just figured out how to get values to work in apreq2 without 
the MAGIC_KEYS hack.  The basic problem is that perl does a lazy
fetch of tied hash values - paraphrasing perlguts, it creates
an empty PVLV that has (PERL_MAGIC_tiedelem) get-magic, so it
doesn't actually FETCH the value until perl demands the value.
So when you write something like 

  my @values = values %$table;

perl generates all the magic PVLV's by iterating over the keys,
and it isn't until the "=" assignment that perl executes the 
FETCH on each value.  The problem is that our iterator (SvCUR(obj))
has already ran through the key list, so it's value is 0 when those
FETCHES are executed.

However, after taking a closer look at how perl constructs the PVLV,
I realized that this issue can be solved by freezing the iterator's
value during the PVLV's construction.  I just committed this idea
to apreq2's cvs by simply cloning the table's SV and copying its 
SvCUR setting, and values() seems to work fine.  This cloning seems
involves a ton of copying overhead, so maybe a better choice of 
iterator could make this be more efficient (after all, it's only
the iterator that we need to clone to get values() working).

-- 
Joe Schaefer