* sleep-for documentation and how to pause reliably
@ 2013-02-15 9:22 Eli Zaretskii
2013-02-15 10:19 ` Thierry Volpiatto
2013-02-15 16:11 ` Stefan Monnier
0 siblings, 2 replies; 12+ messages in thread
From: Eli Zaretskii @ 2013-02-15 9:22 UTC (permalink / raw)
To: emacs-devel
Am I missing something, or is our current docs of sleep-for misleading?
The doc string says:
(sleep-for SECONDS &optional MILLISECONDS)
Pause, without updating display, for SECONDS seconds.
The only way I can interpret this is that sleep-for _always_ pauses
for that number of seconds.
The ELisp manual goes even further:
-- Function: sleep-for seconds &optional millisec
This function simply pauses for SECONDS seconds without updating
the display. It pays no attention to available input. It returns
`nil'. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
Use `sleep-for' when you wish to guarantee a delay.
^^^^^^^^^^^^^^^^^
"Guarantee a delay". No "buts".
However, in fact, sleep-for will return as soon as any input from any
subprocess arrives. E.g., try this in *scratch*:
(progn (setq proc (start-process-shell-command "ls" nil "ls"))
(sleep-for 20)
(message "hi"))
You will see no delay at all before the message is displayed.
Am I missing something? If not, apart of fixing the docs, _is_ there
any way to wait reliably when async subprocesses are running and
producing output?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: sleep-for documentation and how to pause reliably
2013-02-15 9:22 sleep-for documentation and how to pause reliably Eli Zaretskii
@ 2013-02-15 10:19 ` Thierry Volpiatto
2013-02-15 13:18 ` Eli Zaretskii
2013-02-15 16:11 ` Stefan Monnier
1 sibling, 1 reply; 12+ messages in thread
From: Thierry Volpiatto @ 2013-02-15 10:19 UTC (permalink / raw)
To: emacs-devel
Hi Eli,
Eli Zaretskii <eliz@gnu.org> writes:
> Am I missing something, or is our current docs of sleep-for misleading?
>
> The doc string says:
>
> (sleep-for SECONDS &optional MILLISECONDS)
>
> Pause, without updating display, for SECONDS seconds.
>
> The only way I can interpret this is that sleep-for _always_ pauses
> for that number of seconds.
>
> The ELisp manual goes even further:
>
> -- Function: sleep-for seconds &optional millisec
> This function simply pauses for SECONDS seconds without updating
> the display. It pays no attention to available input. It returns
> `nil'. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> [...]
>
> Use `sleep-for' when you wish to guarantee a delay.
> ^^^^^^^^^^^^^^^^^
>
> "Guarantee a delay". No "buts".
>
> However, in fact, sleep-for will return as soon as any input from any
> subprocess arrives. E.g., try this in *scratch*:
>
> (progn (setq proc (start-process-shell-command "ls" nil "ls"))
> (sleep-for 20)
> (message "hi"))
>
> You will see no delay at all before the message is displayed.
>
> Am I missing something? If not, apart of fixing the docs, _is_ there
> any way to wait reliably when async subprocesses are running and
> producing output?
What about using a sentinel?
(progn
(let ((proc (start-process-shell-command "ls" nil "ls")))
(set-process-sentinel proc #'(lambda (process event)
(when (string= event "finished\n"))
(sleep-for 20)
(message "hi after 20s sleeping"))))
(message "Hi now sleeping 20s"))
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: sleep-for documentation and how to pause reliably
2013-02-15 10:19 ` Thierry Volpiatto
@ 2013-02-15 13:18 ` Eli Zaretskii
2013-02-15 20:36 ` Thierry Volpiatto
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2013-02-15 13:18 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Date: Fri, 15 Feb 2013 11:19:27 +0100
>
> > Am I missing something? If not, apart of fixing the docs, _is_ there
> > any way to wait reliably when async subprocesses are running and
> > producing output?
> What about using a sentinel?
>
> (progn
> (let ((proc (start-process-shell-command "ls" nil "ls")))
> (set-process-sentinel proc #'(lambda (process event)
> (when (string= event "finished\n"))
> (sleep-for 20)
> (message "hi after 20s sleeping"))))
> (message "Hi now sleeping 20s"))
Thanks, but that's not what I meant. I meant, suppose you must
reliably wait in a Lisp program that doesn't launch any subprocesses,
but should always wait for N seconds even if there are some async
subprocesses running in parallel. IOW, the code that must pause
doesn't itself launch any subprocesses, it just needs to wait.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: sleep-for documentation and how to pause reliably
2013-02-15 13:18 ` Eli Zaretskii
@ 2013-02-15 20:36 ` Thierry Volpiatto
2013-02-16 8:40 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Thierry Volpiatto @ 2013-02-15 20:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Date: Fri, 15 Feb 2013 11:19:27 +0100
>>
>> > Am I missing something? If not, apart of fixing the docs, _is_ there
>> > any way to wait reliably when async subprocesses are running and
>> > producing output?
>> What about using a sentinel?
>>
>> (progn
>> (let ((proc (start-process-shell-command "ls" nil "ls")))
>> (set-process-sentinel proc #'(lambda (process event)
>> (when (string= event "finished\n"))
>> (sleep-for 20)
>> (message "hi after 20s sleeping"))))
>> (message "Hi now sleeping 20s"))
>
> Thanks, but that's not what I meant. I meant, suppose you must
> reliably wait in a Lisp program that doesn't launch any subprocesses,
> but should always wait for N seconds even if there are some async
> subprocesses running in parallel. IOW, the code that must pause
> doesn't itself launch any subprocesses, it just needs to wait.
Ok.
I tried to run the initial example you sent:
(progn
(setq proc (start-process-shell-command "ls" nil "ls"))
(sleep-for 20)
(message "hi"))
and I noticed that the first time I eval the code Emacs wait for 20s as
expected and on next evaluations it send the message "Hi" immediately
unless I run `list-processes', wait some seconds and reeval it.
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: sleep-for documentation and how to pause reliably
2013-02-15 20:36 ` Thierry Volpiatto
@ 2013-02-16 8:40 ` Eli Zaretskii
2013-02-17 11:58 ` Xue Fuqiao
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2013-02-16 8:40 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 15 Feb 2013 21:36:04 +0100
>
> I tried to run the initial example you sent:
>
> (progn
> (setq proc (start-process-shell-command "ls" nil "ls"))
> (sleep-for 20)
> (message "hi"))
>
> and I noticed that the first time I eval the code Emacs wait for 20s as
> expected and on next evaluations it send the message "Hi" immediately
> unless I run `list-processes', wait some seconds and reeval it.
I never see anything close to 20 sec, neither on Windows nor on
GNU/Linux. The first evaluation takes a little longer (perhaps a
second or two) until I see "hi", but I think this is due to a cold
cache that makes start-process-shell-command slower.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: sleep-for documentation and how to pause reliably
2013-02-16 8:40 ` Eli Zaretskii
@ 2013-02-17 11:58 ` Xue Fuqiao
2013-02-17 16:26 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Xue Fuqiao @ 2013-02-17 11:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, Thierry Volpiatto
On Sat, 16 Feb 2013 10:40:58 +0200
Eli Zaretskii <eliz@gnu.org> wrote:
> > I tried to run the initial example you sent:
> >
> > (progn
> > (setq proc (start-process-shell-command "ls" nil "ls"))
> > (sleep-for 20)
> > (message "hi"))
> >
> > and I noticed that the first time I eval the code Emacs wait for 20s as
> > expected and on next evaluations it send the message "Hi" immediately
> > unless I run `list-processes', wait some seconds and reeval it.
>
> I never see anything close to 20 sec, neither on Windows nor on
> GNU/Linux. The first evaluation takes a little longer (perhaps a
> second or two) until I see "hi", but I think this is due to a cold
> cache that makes start-process-shell-command slower.
Just a question: what does "cold cache" mean? I only know that "cache"
is a collection of data duplicating original values stored elsewhere.
--
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: sleep-for documentation and how to pause reliably
2013-02-17 11:58 ` Xue Fuqiao
@ 2013-02-17 16:26 ` Eli Zaretskii
2013-02-17 23:41 ` Xue Fuqiao
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2013-02-17 16:26 UTC (permalink / raw)
To: Xue Fuqiao; +Cc: emacs-devel, thierry.volpiatto
> Date: Sun, 17 Feb 2013 19:58:13 +0800
> From: Xue Fuqiao <xfq.free@gmail.com>
> Cc: Thierry Volpiatto <thierry.volpiatto@gmail.com>, emacs-devel@gnu.org
>
> > I never see anything close to 20 sec, neither on Windows nor on
> > GNU/Linux. The first evaluation takes a little longer (perhaps a
> > second or two) until I see "hi", but I think this is due to a cold
> > cache that makes start-process-shell-command slower.
>
> Just a question: what does "cold cache" mean?
I meant the disk cache. A cold cache (as opposed to a warm cache)
means that the files your program reads are not in the cache, and need
to be physically read from the disk.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: sleep-for documentation and how to pause reliably
2013-02-15 9:22 sleep-for documentation and how to pause reliably Eli Zaretskii
2013-02-15 10:19 ` Thierry Volpiatto
@ 2013-02-15 16:11 ` Stefan Monnier
2013-02-15 18:24 ` Eli Zaretskii
1 sibling, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2013-02-15 16:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
> However, in fact, sleep-for will return as soon as any input from any
> subprocess arrives.
That'd be a bug.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: sleep-for documentation and how to pause reliably
2013-02-15 16:11 ` Stefan Monnier
@ 2013-02-15 18:24 ` Eli Zaretskii
2013-02-15 20:36 ` Stefan Monnier
2013-03-02 20:48 ` Johan Bockgård
0 siblings, 2 replies; 12+ messages in thread
From: Eli Zaretskii @ 2013-02-15 18:24 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 15 Feb 2013 11:11:43 -0500
>
> > However, in fact, sleep-for will return as soon as any input from any
> > subprocess arrives.
>
> That'd be a bug.
The implementation calls wait_reading_process_output, so I don't see
how it can behave otherwise, unless it calls that function in a loop
until the time passes.
Also, in the meantime I found this in the ELisp manual:
Output from a subprocess can arrive only while Emacs is waiting: when
reading terminal input (see the function `waiting-for-user-input-p'),
in `sit-for' and `sleep-for' (*note Waiting::), and in
`accept-process-output' (*note Accepting Output::). This minimizes the
problem of timing errors that usually plague parallel programming.
So this actually sounds like a deliberate feature.
That said, I don't mind filing a bug report, if you think this should
be fixed.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: sleep-for documentation and how to pause reliably
2013-02-15 18:24 ` Eli Zaretskii
@ 2013-02-15 20:36 ` Stefan Monnier
2013-03-02 20:48 ` Johan Bockgård
1 sibling, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2013-02-15 20:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
>> > However, in fact, sleep-for will return as soon as any input from any
>> > subprocess arrives.
>> That'd be a bug.
> The implementation calls wait_reading_process_output, so I don't see
> how it can behave otherwise, unless it calls that function in a loop
> until the time passes.
I think it should indeed do it in a loop.
> Also, in the meantime I found this in the ELisp manual:
> Output from a subprocess can arrive only while Emacs is waiting: when
> reading terminal input (see the function `waiting-for-user-input-p'),
> in `sit-for' and `sleep-for' (*note Waiting::), and in
> `accept-process-output' (*note Accepting Output::). This minimizes the
> problem of timing errors that usually plague parallel programming.
> So this actually sounds like a deliberate feature.
This doesn't say that it will interrupt sleep-for, only that process
filters will be run during sleep-for.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: sleep-for documentation and how to pause reliably
2013-02-15 18:24 ` Eli Zaretskii
2013-02-15 20:36 ` Stefan Monnier
@ 2013-03-02 20:48 ` Johan Bockgård
1 sibling, 0 replies; 12+ messages in thread
From: Johan Bockgård @ 2013-03-02 20:48 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> That said, I don't mind filing a bug report, if you think this should
> be fixed.
FWIW, it works correctly in Emacs 22.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-03-02 20:48 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-15 9:22 sleep-for documentation and how to pause reliably Eli Zaretskii
2013-02-15 10:19 ` Thierry Volpiatto
2013-02-15 13:18 ` Eli Zaretskii
2013-02-15 20:36 ` Thierry Volpiatto
2013-02-16 8:40 ` Eli Zaretskii
2013-02-17 11:58 ` Xue Fuqiao
2013-02-17 16:26 ` Eli Zaretskii
2013-02-17 23:41 ` Xue Fuqiao
2013-02-15 16:11 ` Stefan Monnier
2013-02-15 18:24 ` Eli Zaretskii
2013-02-15 20:36 ` Stefan Monnier
2013-03-02 20:48 ` Johan Bockgård
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.