Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux]

Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux]

[Andreas Schwab]

"Richard M. Stallman" <rms@gnu.org> writes:

> 3. Execute the following command.
>
>> % emacs -batch -q -no-site-file -l ./foo.el
>
>    Then Emacs exits before the command finishes, and the following
>    error message appears.
>
>> SI/O possible
>
>    The first "S" is the beginning of error message by Emacs, so
>    this is "I/O possible".

The problem is that interrupt_input is always set, but the SIGIO handler
is only installed in !noninteractive mode.  Now make-network-process has
code to call request_sigio after it has finished if interrupt_input is
non-zero, but nobody is handling the SIGIO.

> 4. When you repeat the same command in the same shell process,
>    SIGPOLL will not occur, which seems to be the expected behavior.
>
>> % emacs -batch -q -no-site-file -l ./foo.el
>> Symbol's value as variable is void: foo

I think the reason the SIGIO isn't reported here is that the async
interrupt is still connected to the process group of the previous emacs
instance, which is now defunct, thus there is noone who can receive the
SIGIO.

Probably the best fix is to make (un)request_sigio a no-op in
noninteractive mode.

Andreas.

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

Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux]

[Richard M. Stallman]

    The problem is that interrupt_input is always set, but the SIGIO handler
    is only installed in !noninteractive mode.  Now make-network-process has
    code to call request_sigio after it has finished if interrupt_input is
    non-zero, but nobody is handling the SIGIO.

    Probably the best fix is to make (un)request_sigio a no-op in
    noninteractive mode.

On general principles, it would seem that the best approach is to
handle the SIGIO, just as it would be handled in an interactive Emacs.
That would make all the process-related facilities work right, I would
think.  The only thing to handle differently would be terminal I/O
itself.

Why do you think it is better to make request_sigio a no-op?

Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux]

[Andreas Schwab]

"Richard M. Stallman" <rms@gnu.org> writes:

> Why do you think it is better to make request_sigio a no-op?

SIGIO is only used for keyboard input, so in a noninteractive session it
is not useful.  The only reason make-network-process is fiddling with
request_sigio (according to the comment) is to avoid some problem on Ultix
related to interrupted connect syscall.  The other places that enable
SIGIO are init_sys_modes (no-op when noninteractive) and
redisplay_internal (never called in noninteractive mode).

Andreas.

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

Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux]

[Richard M. Stallman]

    SIGIO is only used for keyboard input, so in a noninteractive session it
    is not useful.

Yes, I remember now.  wait_reading_process_output does not use
signals to determine when processes have output, it just uses
select for that.

So, if you make request_sigio a no-op in batch mode, does that in fact
give correct results?  If so, would you please do it?

Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux]

[Andreas Schwab]

"Richard M. Stallman" <rms@gnu.org> writes:

> So, if you make request_sigio a no-op in batch mode, does that in fact
> give correct results?

Yes, it does.

> If so, would you please do it?

Done.

Andreas.

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