[Top][All Lists]

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

Temporarily disable `timer-event-handler'

From: Alexander Shukaev
Subject: Temporarily disable `timer-event-handler'
Date: Mon, 3 Feb 2020 00:25:00 +0100


I've recently discovered the dark side of Emacs: that timer events run by `timer-event-handler' can be triggered either at `top-level' or at `recursive-edit' or as part of `sit-for' (see `input-pending-p') or `accept-process-output' or `message' (which triggers `redisplay' and subsequently C function `redisplay_internal' that invokes Lisp interpreter machine yet again and hence potentially `timer-event-handler') or maybe even more.

With such plethora of possibilities for `timer-event-handler' to run especially in a nested manner one could even observe an interesting peculiarity:

- Event `A' scheduled to run ASAP.
- Event `B' scheduled to run ASAP.
- The expectation is that `B' strictly runs after `A' finishes execution.
- Well, if `A' calls `message', then according to the above, `A' could indirectly run `timer-event-handler' (nested) which, as a result, will run `B' now essentially somewhere in the middle of `A'. - Clearly, unless taken care of, this may result in side effects and nasty bugs, which are difficult to track down.

Another possible side effect can be related to e.g. `let'-binding, when during an execution of some function some `let'-binding is performed, but `redisplay' is being triggered and some timer event occurs under that `let'-binding, which unfortunately affects it in a buggy unexpected way. Also difficult to understand and hunt down.

Now, first of all, do I understand correctly that the recommended way to temporarily prevent timer events from happening is to `let'-bind both `timer-list' and `timer-idle-list' (similar to how TRAMP does it e.g. in `tramp-accept-process-output')? How about a stock macro for this?

Secondly, does the above explanation, pitfall examples, and recipes to temporarily disable timer events in the middle of Lisp execution appear anywhere in the documentation? I suspect that most users are not aware of this complicated design.

Finally, what's the motivation behind this design? This looks fragile and error-prone to run some arbitrary code in the middle of execution of another code without separating their "stacks" (environment scopes), and even then their global side effects might interfere. Why not only allow timer events to run at "safer" points of execution? E.g. no nested timer events, only at `top-level', never in `redisplay', also allowed in-between some blessed hooks executions?

reply via email to

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