GNU bug report logs - #4954
23.1; Emacs hangs when two run-at-time calls in effect

Previous Next

Full log

Message #15 received at 4954 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Sullivan Beck <sulbeck <at> ufl.edu>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 4954 <at> debbugs.gnu.org
Subject: Re: bug#4954: 23.1; Emacs hangs when two run-at-time calls in effect
Date: Wed, 18 Nov 2009 20:29:10 -0500

On 11/18/2009 6:36 PM, Lennart Borgman wrote:
> On Wed, Nov 18, 2009 at 4:41 PM, Sullivan Beck<sulbeck <at> ufl.edu>  wrote:
>    
>> I wrote two simple emacs extensions, both of which use the run-at-time
>> function periodically write some information to a file. When one or the
>> other is loaded, emacs works fine. When both are loaded, emacs will work
>> fine for a while, and then suddently start behaving very sluggishly.
>> Keyboard input will not be printed on the screen for 2-4 seconds. It
>> never seems to recover (though the periodic work should only take a
>> fraction of a second) and eventually, I have to kill emacs and restart.
>>
>> I'll include both extensions below, though I don't believe that either
>> of them are directly related to the cause of the problem... it just
>> happened that they both use run-at-time.
>>      
> Hi Sullivan,
>
> I do not know what causes the hang, but I can guess. In both your
> extensions you are saving data to a file. I wonder if that operation
> is syncronous? If it is then all Emacs can do is to wait there. (File
> operations can be both async and sync and I do not know what Emacs is
> doing.)
>
>    
It could be... and I certainly considered the fact that perhaps both 
were trying to do something at the same time and were blocking each 
other somehow.

My problem with this is that the slowness doesn't go away once it's 
started. If the two saves are EXACTLY in sync with each other (and it's 
possible... I gave them both a 5 minute interval, and they were 
initialized right after each other), I wouldn't be surprised to see 
emacs become sluggish for a few seconds every 5 minutes.

The problem is that once the sluggishness starts, it persists for 
several minutes. I've never tried to outwait it for too long of a time, 
but I've certainly given it 2-3 minutes, and the sluggishness persists. 
If the two operations can't figure out in that time how to get their 
writes done, I'd say that it has to be a bug in that code.

I'll bet that your suggestion of starting up a run-with-idle-timer would 
be a good workaround (and I may or may not do it... probably not since 
the workaround I've already got is good enough for me).

I mainly submitted the bug so that whoever is in charge of the code that 
runs the timer may look at it. I'm probably at a point where I'm 
satisfied with what I've got, at least for the time being.

Anyway, thanks for the reply.


> A way to work around the trouble is perhaps to rewrite your scheduling
> of the saving operations. Here is one suggestion:
>
> - Instead of saving immediately in the timer start a second timer with
> run-with-idle-timer.
> - In that timer do the saving.
>
> This makes the chance that the saving will occur while you are typing
> a bit smaller, but it does not avoid the trouble totally.
>
>    

Previous Next

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