Email List: Xaustin-group-lX
[All Lists]

Re: Stop signals and interruption of system calls on Linux

To: <yyyyyy@xxxxxxx>
Subject: Re: Stop signals and interruption of system calls on Linux
From: "Michael T Kerrisk" <yyyyyyyyy@xxxxxxx>
Date: Mon, 16 Feb 2004 16:45:01 +0100 (MET)
Cc: yyyyyyy@xxxxxxxxxxxxxxxx, yyyyyy@xxxxxxxxxxx, yyyyyyyyyyyyyy@xxxxxxxxxxxxx
References: <200402161634.i1GGYC828686@webmail.qnx.com>
> 
> 
> Manfred Spraul <yyyyyyy@xxxxxxxxxxxxxxxx> said:
> > Quoting your old comp.std.unix posting:
> > 
> > >However, see subclause 3.3.1.4, which describes the effects of signals
> > >on other functions, and contains:
> > >
> > >    If the action of the signal is to invoke a signal-catching
> > >    function, ... the original function is said to be *interrupted* by
> > >    the signal.
> > >
> > >This, and other wording in 3.3.1.4 makes it clear, I think, that the
> > >bit about EINTR in the description of read() does not apply to job
> > >control signals that were not caught.
> > 
> > Does that mean that signals that are not delivered to user space should 
> > never cause a syscall to return with -1, errno=EINTR?
> 
> No, the bit about EINTR is just a requirement that the syscall must fail
and 
> set errno to a particular value in particular circumstances.  In 
> circumstances where no such requirement applies, the syscall is still free
to 
> fail and set errno to whatever the implementor felt appropriate, including
> EINTR.
> 
> Unless, of course, the standard says somewhere that the call is not
allowed 
> to fail in those circumstances.  One can argue that the quote about how a 
> function is supposed to continue after an SIGCONT says just that, but I'm
not 
> sure that it says it clearly enough to let you sue an implementor and win 
> money from him...

Hello Wojtek,

While I'm guess that you are taking a devil's advocate position here,
I assume that we agree that the natural (and probably intended)
interpretation of the standard is: 

1. EINTR will occur when a system call is interrupted by a 
   signal *handler*.

2. In the absence of a signal handler, the combination of a 
   stop-signal+SIGCONT will be invisible to the the receiving 
   process (i.e., it will continue execution as though nothing 
   happened).  

As far as I know, those two statements hold true on every 
contemporary implementation, except Linux.

Cheers,

Michael

-- 
Michael Kerrisk
yyyyyyyyy@xxxxxxx

GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++

<Prev in Thread] Current Thread [Next in Thread>