On Wed, Jun 30, 2010 at 09:24:42AM -0600, Alex Hunsaker wrote:
> On Wed, Jun 30, 2010 at 02:49, Tim Bunce <tim.bu...@pobox.com> wrote:
> > On Tue, Jun 29, 2010 at 09:50:00PM -0700, Fred Moyer wrote:
> >> I think getting rid of the segfault is a good thing. But if the main
> >> problem is issues with NYTProf, then it seems like this change won't
> >> solve the core problem of autogenerated null end blocks faulting. I'm
> >> don't fully understand the scope of these issues yet, so my answers
> >> (and questions) may not be completely helpful.
>
> Well, the point of the test case is it does not use NYTProf. Sure It
> was found while playing with NYTProf. :)
>
> > I suggest the code shift items off the main array, like perl does,
> > but also push those items onto a new temp array.
> > When there are no more items in the main array it would copy
> > the items back again (av_make() is handy for that).
>
> Wouldn't the list keep getting longer each time? For example take
> your test case:
> END { eval "END { }" for 1..10 }
>
> The first time we run them we should shift of 11 items. The next time
> 21, etc. Am I missing something? Perhaps some cool trick? Thats why
> I was thinking local() or equiv would make the most sense.
I presume mod_perl doesn't shift the array because it wants the array to
persist to be used again later. If not then it should shift.
Otherwise running 11 the first and 21 the second is the right behavior
for this (very unusual) test case.
Tim.
p.s. I'm not familar enough with mod_perl not know the all issues
surrounding how it uses PL_endav. So if this thread continues I'd be
grateful if someone could give some background/context. Thanks.
