Re: Output disappears when using interrupt key

hzsbg01!jbuhrma@hvgtw.att.com
Thu, 15 Apr 93 09:24:54 +0200

> On an SGI (System V, though with lots of BSD extensions) the ^C
> triggers the except clause right away (as it should).
^^^^^^^^^^^^
> [...] On System V-like systems, the signal handler causes the read()
> system call that's buried deep inside stdio to return with an error
> (EINTR is set), causing the stdio getc() call in Python (in
> "fileobject.c", getline()) to return EOF, after which getline() checks
> for an interrupt and reports an error -- the sys.stdin.readline() call
> never returns successful.

> However, on BSD-like systems, by default the read() call is
> *restarted* after a signal handler returns normally

> [...] A solution? Maybe I should just check for an interrupt after
> *every* read, not just when getc() returns EOF. This would be
> somewhat expensive (an extra function call for *every* readline() and
> read() call), but it could be made less expensive by doing it only for
> tty devices (adding a field to the internal file structure containing
> the outcome of isatty()).

Another possibility: Let BSD-like system calls react on interrupts the
same way as is done on System V based systems. You probably already
know this, but the read(2) man page for SunOS 4.1.3 suggests that this
is possible:

If the process calling read() or readv() receives a signal
before any data are read, the system call is restarted
unless the process explicitly set the signal to interrupt
the call using sigvec() or sigaction() (see the discussions
of SV_INTERRUPT on sigvec(2) and SA_INTERRUPT on
sigaction(3V)). If read() or readv() is interrupted by a
signal after successfully reading some data, it returns the
number of bytes read.

Regards,

-- Jan-Hein Buhrman -- AT&T Huizen NL -- <jbuhrma%hzsbg01@hvlpa.att.com> --
---------------------- +31 35 87.4278 --- ...!att!hvlpa!hzsbg01!jbuhrma ---
``Relax..., you're quite safe here'' --- Lady on Art of Noise's Paranoimia