Re: another subtle signals issue

From: Linus Torvalds (torvalds@transmeta.com)
Date: Tue Feb 11 2003 - 23:21:02 EST


On Tue, 11 Feb 2003, Roland McGrath wrote:
>
> I'm not talking about reading from pipes, that was your example.

The reason I harp on pipes is that I remember something like that breaking
real programs in the past, which is a lot more important.

(Thinking about it, it can't have been pipe reading, it must have been
writing. Reading a pipe always returns partial results early if it is
successful. Writing doesn't. Trivial test-case appended, see what happens
when you ^Z it. And realize that more programs care about this than about
timed semaphore operations).

> I was
> talking about calls with timeouts, like semop, whose interface do not
> permit partial results.

And I have multiple times said that as far as Linux is concerned, ^Z is,
has always been, and certainly for the 2.6.x timeframe _will_ be a signal
that the kernel considers "caught".

Another way of saying it: just leave the system calls alone. If they
aren't restartable, they have to return -EINTR. And if you think that
disagrees with POSIX, and if RH really wants certification, then you
should advice RH to document the difference as just that - a difference.
And push it through as such.

Anyway, try out the following test-program in an xterm. Resize the xterm
and see what happens. Press ^Z and see what happens. I'm saying that the
^Z behaviour is something Linux always has done (and as such not something
you should worry about overmuch), while the SIGWINCH behaviour is new with
the new signal handling code and _is_ worrysome, since that can break old
programs (but I think your patch fixes it, so I'm not worried).

To recap:
 - common functions are a lot more important than uncommon ones (which is
   why the pipe thing is interesting)
 - old behaviour is a lot more important than POSIX (existing binaries
   have all been tested with old behaviour).

Considering that the SIGCHLD:SIG_IGN change to child reaping apparently
broke at least one existing program, I hope you can see my point. At some
point it just doesn't _matter_ what POSIX says.

                Linus

---
#include <signal.h>
#include <stdio.h>

#define SIZE 131072

int main(void) { char buffer[SIZE]; int fd[2];

pipe(fd); write(fd[1], buffer, SIZE); }

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:00:37 EST