bug#1082: 23.0.60; read-char unexpectedly halts execution of script

bug#1082: 23.0.60; read-char unexpectedly halts execution of script

[Markus Triska]

Let filter.el consist of the forms:

   (defun bc-filter (proc string)
     (message "%s" string))

   (message "starting")
   (setq bc (start-process "bc" nil "/usr/bin/bc"))
   (set-process-filter bc 'bc-filter)

   (while t
     (let ((char (read-char nil nil 0.1)))
       (message "char: %s" char)))

Where "/usr/bin/bc" is the GNU arbitrary precision calculator. Now:

   mt-computer:~ mt$ emacs --script filter.el
   starting
   mt-computer:~ mt$

I expect non-termination in this case, as in eval-buffer on filter.el.

In GNU Emacs 23.0.60.1 (i386-apple-darwin8.11.1, GTK+ Version 2.12.9)
 of 2008-09-24 on mt-computer.local
Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000
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_GB.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

bug#1082: 23.0.60; read-char unexpectedly halts execution of script

[Chong Yidong]

> Let filter.el consist of the forms:
>
>    (defun bc-filter (proc string)
>      (message "%s" string))
>
>    (message "starting")
>    (setq bc (start-process "bc" nil "/usr/bin/bc"))
>    (set-process-filter bc 'bc-filter)
>
>    (while t
>      (let ((char (read-char nil nil 0.1)))
>        (message "char: %s" char)))
>
> Where "/usr/bin/bc" is the GNU arbitrary precision calculator. Now:
>
>    mt-computer:~ mt$ emacs --script filter.el
>    starting
>    mt-computer:~ mt$
>
> I expect non-termination in this case, as in eval-buffer on filter.el.

This broke when SYNC_INPUT became the default; it works when Emacs is
recompiled without SYNC_INPUT, like Emacs 22.

I don't know what the specific cause of failure is, however.  Maybe the
SYNC_INPUT code should only be active when Emacs is run interactively.

Thoughts?

bug#1082: 23.0.60; read-char unexpectedly halts execution of script

[Lennart Borgman (gmail)]

Chong Yidong wrote:
>> Let filter.el consist of the forms:
>>
>>    (defun bc-filter (proc string)
>>      (message "%s" string))
>>
>>    (message "starting")
>>    (setq bc (start-process "bc" nil "/usr/bin/bc"))
>>    (set-process-filter bc 'bc-filter)
>>
>>    (while t
>>      (let ((char (read-char nil nil 0.1)))
>>        (message "char: %s" char)))
>>
>> Where "/usr/bin/bc" is the GNU arbitrary precision calculator. Now:
>>
>>    mt-computer:~ mt$ emacs --script filter.el
>>    starting
>>    mt-computer:~ mt$
>>
>> I expect non-termination in this case, as in eval-buffer on filter.el.
> 
> This broke when SYNC_INPUT became the default; it works when Emacs is
> recompiled without SYNC_INPUT, like Emacs 22.
> 
> I don't know what the specific cause of failure is, however.  Maybe the
> SYNC_INPUT code should only be active when Emacs is run interactively.
> 
> Thoughts?


What is the while loop supposed to do? I tested just that and I got a
bit weird results.

bug#1082: 23.0.60; read-char unexpectedly halts execution of script

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Let filter.el consist of the forms:
>>
>>    (defun bc-filter (proc string)
>>      (message "%s" string))
>>
>>    (message "starting")
>>    (setq bc (start-process "bc" nil "/usr/bin/bc"))
>>    (set-process-filter bc 'bc-filter)
>>
>>    (while t
>>      (let ((char (read-char nil nil 0.1)))
>>        (message "char: %s" char)))
>>
>> Where "/usr/bin/bc" is the GNU arbitrary precision calculator. Now:
>>
>>    mt-computer:~ mt$ emacs --script filter.el
>>    starting
>>    mt-computer:~ mt$
>>
>> I expect non-termination in this case
>
> This broke when SYNC_INPUT became the default.

To pin it down further, this breakage seems to be due to not using
SA_RESTART in the signal handler.  If we set SA_RESTARTi in sysdep.c,
the problem disappears.  Stefan, could you comment?

signal_handler_t
sys_signal (int signal_number, signal_handler_t action)
{
  struct sigaction new_action, old_action;
  sigemptyset (&new_action.sa_mask);
  new_action.sa_handler = action;
#if defined (SA_RESTART) && ! defined (BROKEN_SA_RESTART) && !defined(SYNC_INPUT)
  /* Emacs mostly works better with restartable system services. If this
     flag exists, we probably want to turn it on here.
     However, on some systems this resets the timeout of `select'
     which means that `select' never finishes if it keeps getting signals.
     BROKEN_SA_RESTART is defined on those systems.  */
  /* It's not clear why the comment above says "mostly works better".  --Stef
     When SYNC_INPUT is set, we don't want SA_RESTART because we need to poll
     for pending input so we need long-running syscalls to be interrupted
     after a signal that sets the interrupt_input_pending flag.  */
  new_action.sa_flags = SA_RESTART;
#else
  new_action.sa_flags = 0;
#endif
  sigaction (signal_number, &new_action, &old_action);
  return (old_action.sa_handler);
}

bug#1082: 23.0.60; read-char unexpectedly halts execution of script

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Let filter.el consist of the forms:
>>
>>    (defun bc-filter (proc string)
>>      (message "%s" string))
>>
>>    (message "starting")
>>    (setq bc (start-process "bc" nil "/usr/bin/bc"))
>>    (set-process-filter bc 'bc-filter)
>>
>>    (while t
>>      (let ((char (read-char nil nil 0.1)))
>>        (message "char: %s" char)))
>>
>> Where "/usr/bin/bc" is the GNU arbitrary precision calculator. Now:
>>
>>    mt-computer:~ mt$ emacs --script filter.el
>>    starting
>>    mt-computer:~ mt$
>>
>> I expect non-termination in this case, as in eval-buffer on filter.el.
>
> This broke when SYNC_INPUT became the default; it works when Emacs is
> recompiled without SYNC_INPUT, like Emacs 22.
>
> I don't know what the specific cause of failure is, however.  Maybe the
> SYNC_INPUT code should only be active when Emacs is run interactively.
>
> Thoughts?

In non-interactive mode we always want restartable syscalls, since
keyboard input goes through stdio (SYNC_INPUT makes no difference here).
I've checked in a fix.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#1082: 23.0.60; read-char unexpectedly halts execution of script

[Markus Triska]

Andreas Schwab <schwab@suse.de> writes:

> In non-interactive mode we always want restartable syscalls, since
> keyboard input goes through stdio (SYNC_INPUT makes no difference here).
> I've checked in a fix.

Thank you, it fixes this problem for me. Could process output also be
handled, as in interactive use? E.g., M-x eval-region on the forms:

   (defun bc-filter (proc string)
     (message "%s" string))

   (message "starting")
   (setq bc (start-process "bc" nil "/usr/bin/bc"))
   (set-process-filter bc 'bc-filter)

   (while t
     (let ((char (read-char nil nil 0.1)))
       (when char
         (message "char: %s" char))))

processes the output of bc, and shows:

   starting
   bc 1.06
   Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
   This is free software with ABSOLUTELY NO WARRANTY.
   For details type `warranty'.

Whereas in "emacs --script" mode, this output is not shown.

bug#1082: 23.0.60; read-char unexpectedly halts execution of script

[Stefan Monnier]

> In non-interactive mode we always want restartable syscalls, since
> keyboard input goes through stdio (SYNC_INPUT makes no difference here).
> I've checked in a fix.

Thank you.  Could you add a comment explaining why we test
`noninteractive' at that spot, please?


        Stefan