On May 12, 4:09am, Joshua N Pritikin wrote:
> On Sun, May 12, 2002 at 01:10:03AM -0400, Allen Smith wrote:
> > On May 11, 11:28pm, Joshua N Pritikin wrote:
> > > That means that Event probably has a reference counting bug.
> >
> > Sigh... yes. I am wondering myself about a couple things in ev.c:
> > A. pe_event_invoke. Callbacks only return values via calling
> > "unloop('value')", not returning something, right? Thus the
> > G_VOID? Then why not also G_DISCARD?
>
> Look at the source code for call_sv in perl.c. The only things that
> G_DISCARD does is turn on the ENTER/SAVETMPS FREETMPS/LEAVE pair.
> This is already done in _loop() so we don't need to do it again.
> i tried adding G_DISCARD and it doesn't make any difference.
Ah. I'd put it in in case of future changes in perl, still... but something
else of interest: if one substitutes while(1) {sweep();} for loop();, the
leak doesn't seem to happen, even giving it quite a while - even if it does
happen, it's definitely _per-iteration_ slower than with loop.
> > B. pe_event_release decreases the refcount for ev->mysv; the same
> > happens in event_2sv thanks to the "sv_2mortal", which
> > compensates for the SvREFCNT_inc. But ev->mysv is a
> > reference. What decreases the refcount to the thing it's
> > referring to?
>
> When the rv is destroyed then it does a SvREFCNT_dec on the SV to which it
> is pointing. See the doc for newSVrv -- the sv is created with a
> refcnt=1, so this should work. You can verify it with
> $Event::DebugLevel=3; which turns on a warning "Event=0x%x '%s' destroyed
> (SV=0x%x)".
>
> Oops, this warning isn't getting triggered.
It isn't? It does for me, whether one calls "loop" _or_ "sweep".
> i don't have much time but i'll try to look at this today.
Understand!
-Allen
--
Allen Smith http://cesario.rutgers.edu/easmith/
September 11, 2001 A Day That Shall Live In Infamy II
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin
