GNU bug report logs -
#12447
24.1.50; Stuck in garbage collection on OS X
Previous Next
Full log
Message #52 received at 12447 <at> debbugs.gnu.org (full text, mbox):
On 16.09.2012 16:39, Eli Zaretskii wrote:
>> Date: Sun, 16 Sep 2012 16:07:07 +0400
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> CC: hanche <at> math.ntnu.no, 12447 <at> debbugs.gnu.org
>>
>>>> Like I wrote in 12326, AFAICT, the problem is that timer_check_2 doesn't
>>>> at any point check that Emacs is still idle. When run-with-idle-timer
>>>> calls (timer-activate-when-idle timer t), the new timer is added to the
>>>> list, timer_check_2 reaches is and runs it immediately because
>>>> 'timer_idleness_start_time' still has the same value.
>>>
>>> If that is the problem, then perhaps having timer_check_2 work on a
>>> copy of the list would solve the problem. Did you try that?
>>
>> I'm no C programmer, so I didn't try to fix it in C code. How would I
>> make a copy of a list there?
>
> Using the Fcopy_sequence function, I'd think. Use it at the beginning
> of the function to set the value of 'idle_timers', instead of this
> line:
>
> idle_timers = Vtimer_idle_list;
Done that, recompiled, no difference in the example a sent previously.
Exactly because, I think, of the control flow you describe below:
>> But no, it probably won't: the "guilty" commit made timer_check_2
>> actually return 0 after a timer fires (keeping true to the comment above
>> it), so a local copy would serve no purpose.
>
> timer_check_2 indeed returns, but then timer_check will call it again,
> because it continues calling timer_check_2 in a loop, until there's no
> ripe timer.
Each time timer_check_2 is called, a new copy would be made from the
idle timers list, so the newly created timer would be reached during the
same call to 'timer_check'.
This bug report was last modified 12 years and 247 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.