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

[sbaugh@catern.com]

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...