Front page | perl.perl5.porters |
Postings from August 2011
On Sun, Jul 24, 2011 at 01:53:15PM -0700, Father Chrysostomos wrote:
> Nicholas Clark wrote:
> > One can't do it trivially that way without breaking existing semantics.
> > Internally, scalars are passed around as (RVALUE) pointers to (LVALUE)
> > SV structures. Effectively, at the C level, everything is a form of
> > reference, and C code has to work on the scalar in place.
> >
> > Currently the C code croaks if what is has been passed is read-only.
> > If one wanted to change to the C code to on-demand create a new read-write
> > copy of a read-only value, then every function would have to have a way to
> > return a new SV * address of each of its operand that "moved".
> >
> > If instead one wanted to keep the current C APIs, and replace the "croak on
> > read only" check with a "cheap COW copy of the value", keeping the same
> > SV * address, then one would have to change how constants are put onto the
> > Perl stack. Currently the address of the SV stored in the optree (1 pointer)
> > is placed on the Perl stack, without any refcounting:
> >
> > PP(pp_const)
> > {
> > dVAR;
> > dSP;
> > XPUSHs(cSVOP_sv);
> > RETURN;
> > }
> >
> > To allow mutation, even by copy-on-write, then the above code would have to
> > change to allocate a new SV * (each time), which would be quite a performance
> > hit, given that each newly allocated SV would also have to be stored on the
> > mortal stack to ensure that it was cleaned up at the end of the statement.
>
> What about marking SVs in the op tree with the PADTMP flag?
That doesn't solve any of the above problems. pp_const would still be pushing
the same SV * pointer onto the Perl stack each time.
One still has to either
a: change pp_const to create a new SV head, so that C functions are able to
modify that SV without changing the one in the optree.
or
b: keep the SV on the stack the same, but change C functions to return a
result SV, which may be different from the passed-in SV
The problem isn't the flags on the SV. The problem is that the memory address
passed around is that of the (master constant) SV in the optree.
Nicholas Clark
Thread Previous
|
Thread Next