develooper Front page | perl.perl5.porters | Postings from May 2013

Re: SPAGAIN/PUTBACK trip hazards (was Re: [perl #78674] stack pointercorruption in pp_concat() with 'use encoding')

Thread Previous
From:
Leon Timmermans
Date:
May 8, 2013 15:41
Subject:
Re: SPAGAIN/PUTBACK trip hazards (was Re: [perl #78674] stack pointercorruption in pp_concat() with 'use encoding')
Message ID:
CAHhgV8ie7q7gGVXViCT9D=x35Bpea4wkCziF2r1kZ2iVUsfz-w@mail.gmail.com
On Wed, May 8, 2013 at 2:18 PM, Nicholas Clark <nick@ccl4.org> wrote:
> I can't find any.
>
> I was wondering, is a better solution to this whole problem to ensure that
> anything that creates an inferior runloop does so on a freshly allocated
> stack?

A number of magical thingies already do such a thing, it does make
sense to me given circumstances.

> The whole paradigm of needing to get and "put back" a local copy of the
> stack pointer seems fragile, and something that dates from an age of machines
> with much tighter resource constraints.

Yeah, it's fairly annoying, though AFAIK it can't be made no-op
without subtly breaking backwards compatibility. A simpler stack
discipline may be nice to have though it may be too late for that.
Then again, stack refcounting is probably a bigger and harder issue.

> (Heck, and effectively predates common use of tie, overloading, PerlIO and
> the growing supply of hooks which can end up running code within what looks
> like an innocent C function call)

Yeah. It's an optimization that might not be an optimization anymore.
I mean, the cost of creating new stacks occasionally may be higher
than the gain of mostly working with local variables.

Leon

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About