bug#2930: 23.0.92; `accept-process-output' and `sleep-for' do not run sentinels

bug#2930: 23.0.92; `accept-process-output' and `sleep-for' do not run sentinels

[Markus Triska]

The documentation for sentinels states:

   A program can wait, so that sentinels will run, by calling
   `sit-for' or `sleep-for' (...), or `accept-process-output' (...).

However, when I do M-x eval-region RET on the following forms in
"emacs -Q", then Emacs loops unexpectedly:

   (defun my-sentinel (proc str)
     (setq my-finished t))

   (let ((p (start-process "bc" nil "bc"))
         my-finished)
     (set-process-sentinel p 'my-sentinel)
     (process-send-string p "quit\n")
     (while (not my-finished)
       (accept-process-output nil 0.1)))

When I replace the call of `accept-process-output' with (sleep-for
0.1), it also does not run the sentinel. (sit-for 0.1) works as
documented, but is not a good alternative for the other functions in
this case: If keyboard input is available, `sit-for' returns
immediately, so it is currently unfortunately also necessary to
discard keyboard input to make such a loop reliably run the sentinel.

In GNU Emacs 23.0.92.2 (i386-apple-darwin9.6.1, GTK+ Version 2.14.7)
 of 2009-04-05 on mt-imac.local
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure  '--with-tiff=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

bug#2930: 23.0.92; `accept-process-output' and `sleep-for' do not run sentinels

[Stefan Monnier]

>    (let ((p (start-process "bc" nil "bc"))
>          my-finished)
>      (set-process-sentinel p 'my-sentinel)
>      (process-send-string p "quit\n")
>      (while (not my-finished)
>        (accept-process-output nil 0.1)))

What happens of you pass `p' to accept-process-output, as would
seem natural?


        Stefan

bug#2930: 23.0.92; `accept-process-output' and `sleep-for' do not run sentinels

[Markus Triska]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>      (while (not my-finished)
>>        (accept-process-output nil 0.1)))
>
> What happens of you pass `p' to accept-process-output

It also loops, both with and without additional time-out, i.e.:

   (accept-process-output p)

and

   (accept-process-output p 0.1)

and not specifying any particular process all yield the same result.

bug#2930: 23.0.92; `accept-process-output' and `sleep-for' do not run sentinels

[Chong Yidong]

> The documentation for sentinels states:
>
>    A program can wait, so that sentinels will run, by calling
>    `sit-for' or `sleep-for' (...), or `accept-process-output' (...).
>
> However, when I do M-x eval-region RET on the following forms in
> "emacs -Q", then Emacs loops unexpectedly:
>
>    (defun my-sentinel (proc str)
>      (setq my-finished t))
>
>    (let ((p (start-process "bc" nil "bc"))
>          my-finished)
>      (set-process-sentinel p 'my-sentinel)
>      (process-send-string p "quit\n")
>      (while (not my-finished)
>        (accept-process-output nil 0.1)))

The trouble is that accept-process-output passes a zero DO_DISPLAY
argument to wait_reading_process_output (process.c:4306).  When
DO_DISPLAY is zero, status notifications are not performed
(process.c:4763).

Having accept-process-output pass a non-zero DO_DISPLAY argument to
wait_reading_process_output fixes this problem, but I don't know what
ramifications this would have.

Stefan, WDYT?

bug#2930: 23.0.92; `accept-process-output' and `sleep-for' do not run sentinels

[Stefan Monnier]

>> The documentation for sentinels states:
>> A program can wait, so that sentinels will run, by calling
>> `sit-for' or `sleep-for' (...), or `accept-process-output' (...).
>> 
>> However, when I do M-x eval-region RET on the following forms in
>> "emacs -Q", then Emacs loops unexpectedly:
>> 
>> (defun my-sentinel (proc str)
>> (setq my-finished t))
>> 
>> (let ((p (start-process "bc" nil "bc"))
>> my-finished)
>> (set-process-sentinel p 'my-sentinel)
>> (process-send-string p "quit\n")
>> (while (not my-finished)
>> (accept-process-output nil 0.1)))

> The trouble is that accept-process-output passes a zero DO_DISPLAY
> argument to wait_reading_process_output (process.c:4306).  When
> DO_DISPLAY is zero, status notifications are not performed
> (process.c:4763).

> Having accept-process-output pass a non-zero DO_DISPLAY argument to
> wait_reading_process_output fixes this problem, but I don't know what
> ramifications this would have.

I don't know.  You already changed it in that direction a year ago:

   timestamp: Mon 2008-05-19 22:29:33 +0000
   message:
     (wait_reading_process_output): Always check status when in batch mode.

so maybe we should change it even further?  I think a good change would
be to change the code of wait_reading_process_output such that status
changes are taken into account (even when do_display is 0) but only for
the process(es) for which we're waiting.


        Stefan

bug#2930: 23.0.92; `accept-process-output' and `sleep-for' do not run sentinels

[Markus Triska]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> so maybe we should change it even further?  I think a good change would
> be to change the code of wait_reading_process_output such that status
> changes are taken into account (even when do_display is 0) but only for
> the process(es) for which we're waiting.

I agree, and I think that if no process at all is specified, then all
status changes should be processed. This is for consistency with regular
input processing: If there is input from some process, and no particular
process is specified, it will also be processed.

bug#2930: 23.0.92; `accept-process-output' and `sleep-for' do not run sentinels

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I don't know.  You already changed it in that direction a year ago:
>
>    timestamp: Mon 2008-05-19 22:29:33 +0000
>    message:
>      (wait_reading_process_output): Always check status when in batch mode.
>
> so maybe we should change it even further?  I think a good change would
> be to change the code of wait_reading_process_output such that status
> changes are taken into account (even when do_display is 0) but only for
> the process(es) for which we're waiting.

OK, thanks for reminding me about Bug#131.  After re-reading that
discussion, I'm fairly sure that TRT is for wait_reading_process_output
to always check the process status (without triggering a redisplay
unless DO_DISPLAY is non-zero).  I've checked the change into CVS.