emacs-devel
[Top][All Lists]
Advanced

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

Re: call-process should not block process filters from running


From: sbaugh
Subject: Re: call-process should not block process filters from running
Date: Tue, 04 Jul 2023 09:51:42 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

Po Lu <luangruo@yahoo.com> writes:
> sbaugh@catern.com writes:
>
>> AFAIK, timers don't run concurrently with themselves.  If a timer
>> function is running, a second instance of that function won't run until
>> the first one is finished.
>
> That is untrue.  Instead, we discourage timer functions that are not
> reentrant from calling functions which may check for input (such as
> sit-for or read-event, and notably not call-process.)

If I run

(run-at-time "0 sec" 1
             (lambda ()
               (message "in sleepy timer %s" (float-time))
               (sit-for 10)))

I get a message every 10 seconds, instead of every second.  Why is this?
I assumed it was because we don't run a single timer instance
concurrently with itself.

(info "(elisp) Timers") says

>Timer functions should also avoid calling functions that cause Emacs to
>wait, such as ‘sit-for’ (*note Waiting::).  This can lead to
>unpredictable effects, since other timers (or even the same timer) can
>run while waiting.

But it seems that the "(or even the same timer)" part is not true in
practice.  From looking at timer-event-handler this makes sense - it
looks like we remove the timer from timer-list before running it.  So
timers don't run concurrently with themselves.  Which since it's already
the case, we might as well formalize, since it's useful for Lisp
programmers...




reply via email to

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