* Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux] [not found] <E1EOp4L-0001CX-C8@fencepost.gnu.org> @ 2005-10-10 10:00 ` Andreas Schwab 2005-10-10 23:47 ` Richard M. Stallman 0 siblings, 1 reply; 5+ messages in thread From: Andreas Schwab @ 2005-10-10 10:00 UTC (permalink / raw) Cc: emacs-devel "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." ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux] 2005-10-10 10:00 ` [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux] Andreas Schwab @ 2005-10-10 23:47 ` Richard M. Stallman 2005-10-11 13:23 ` Andreas Schwab 0 siblings, 1 reply; 5+ messages in thread From: Richard M. Stallman @ 2005-10-10 23:47 UTC (permalink / raw) Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux] 2005-10-10 23:47 ` Richard M. Stallman @ 2005-10-11 13:23 ` Andreas Schwab 2005-10-13 4:53 ` Richard M. Stallman 0 siblings, 1 reply; 5+ messages in thread From: Andreas Schwab @ 2005-10-11 13:23 UTC (permalink / raw) Cc: emacs-devel "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." ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux] 2005-10-11 13:23 ` Andreas Schwab @ 2005-10-13 4:53 ` Richard M. Stallman 2005-10-13 9:30 ` Andreas Schwab 0 siblings, 1 reply; 5+ messages in thread From: Richard M. Stallman @ 2005-10-13 4:53 UTC (permalink / raw) Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux] 2005-10-13 4:53 ` Richard M. Stallman @ 2005-10-13 9:30 ` Andreas Schwab 0 siblings, 0 replies; 5+ messages in thread From: Andreas Schwab @ 2005-10-13 9:30 UTC (permalink / raw) Cc: emacs-devel "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." ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-10-13 9:30 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <E1EOp4L-0001CX-C8@fencepost.gnu.org> 2005-10-10 10:00 ` [czkmt@remus.dti.ne.jp: open-network-stream in batch mode causes SIGPOLL under GNU/Linux] Andreas Schwab 2005-10-10 23:47 ` Richard M. Stallman 2005-10-11 13:23 ` Andreas Schwab 2005-10-13 4:53 ` Richard M. Stallman 2005-10-13 9:30 ` Andreas Schwab
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).