unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Temporarily disable `timer-event-handler'
@ 2020-02-02 23:25 Alexander Shukaev
  2020-02-03  1:36 ` Drew Adams
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Alexander Shukaev @ 2020-02-02 23:25 UTC (permalink / raw)
  To: help-gnu-emacs, emacs-devel

Hi,

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?



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-02-05 15:09 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-02 23:25 Temporarily disable `timer-event-handler' Alexander Shukaev
2020-02-03  1:36 ` Drew Adams
2020-02-03  8:23 ` Michael Albinus
2020-02-03 14:01 ` Stefan Monnier
2020-02-03 15:44   ` Eli Zaretskii
2020-02-04 22:30     ` Alexander Shukaev
2020-02-05  0:53       ` Stefan Monnier
2020-02-05  1:21         ` Alexander Shukaev
2020-02-05  1:30           ` Stefan Monnier
2020-02-05 14:29           ` Eli Zaretskii
2020-02-05 15:09             ` Michael Albinus

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).