bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sullivan Beck
Subject: bug#4954: 23.1; Emacs hangs when two run-at-time calls in effect
Date: Wed, 18 Nov 2009 20:29:10 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4

On 11/18/2009 6:36 PM, Lennart Borgman wrote:
On Wed, Nov 18, 2009 at 4:41 PM, Sullivan Beck<address@hidden>  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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]