emacs-devel
[Top][All Lists]
Advanced

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

Re: Temporarily disable `timer-event-handler'


From: Alexander Shukaev
Subject: Re: Temporarily disable `timer-event-handler'
Date: Tue, 4 Feb 2020 23:30:45 +0100

On 03/02/2020 16:44, Eli Zaretskii wrote:
[I removed help-gnu-emacs from the CC list.]

From: Stefan Monnier <address@hidden>
Date: Mon, 03 Feb 2020 09:01:47 -0500
Cc: address@hidden, address@hidden

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),

It's a direct consequence of the implementation, rather than the result
of design, AFAICT.

There's also the need to run a timer as close to its expected time as
possible, so waiting for any Lisp to return might delay timers too
much.


Right, the current implementation looks more like coroutines, where certain built-in functions yield for timers to run on occasion. This is indeed likely to be more performent and even useful at times, i.e. example from Stefan

But there can also be cases where A does want/need B to be processed
before A ends.

Nonetheless, given the availability of dynamic binding, I find this error-prone. Is there currently a way in Emacs Lisp to run a function within a separate stack, i.e. free of any "user-defined" dynamic bindings? I would imagine that this may be the right solution to fire timer events in this manner as it then does not matter whether they run in the middle of other routines.

Additionally, I believe the solution to fulfill

The expectation is that `B' strictly runs after `A' finishes execution.

is also missing. Some sort of macro (aka `ignore-timers') which essentially forbids yielding during the execution of the enclosed body, while `let'-binding both `timer-list' and `timer-idle-list' as a naive implementation of such does not really scale, since any inner calls to `cancel-timer' or otherwise scheduling other (new) timer events would have bad side effects. Otherwise, should be something simple and similar to `inhibit-redisplay', aka `inhibit-timers' and `inhibit-idle-timers'.



reply via email to

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