GNU bug report logs - #21380
25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, pipcet <at> gmail.com, 21380 <at> debbugs.gnu.org
Subject: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook
Date: Sat, 05 Sep 2015 18:27:30 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: rudalics <at> gmx.at,  pipcet <at> gmail.com,  21380 <at> debbugs.gnu.org
> Date: Sat, 05 Sep 2015 11:18:54 -0400
> 
> > I'm not sure I understand this plan.  Are you saying that consing a
> > new list in timer--activate, instead of reusing an existing cell, will
> > avoid the need to wok on a copy of the timer's list when invoking the
> > timer callbacks?
> 
> That's the idea, yes.
> 
> > If so, I'm probably missing something here, because
> > timer--activate will update the timer list variable anyway,
> 
> This is OK: by this time, we've already read this timer list variable so
> changing it won't affect us.

What do you mean by "have read the variable"?  We are "reading" it one
member at a time, as timer_check goes about its business.

> > Not to mention the fact that with timers firing every several tens of
> > ms, something we've seen while discussing these bugs, allocating a
> > couple of cells each time might cause a lot of consing per second,
> > which in turn causes GC, which slows down everything.
> 
> How could it be worse to allocate cells when we activate a timer than
> copying the whole list every time we check the timers?

Twice worse, I'd say (assuming "a couple" really means 2).

But this is not the important issue right now.  Right now, I don't
understand how your proposal will solve this and related bugs.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.