Re: SIGCONT misbehaviour in Linux

Richard B. Johnson (root@chaos.analogic.com)
Wed, 8 Dec 1999 16:41:37 -0500 (EST)


On 8 Dec 1999, H. Peter Anvin wrote:

> Followup to: <19991208100219.A18129@stormix.com>
> By author: Simon Kirby <sim@stormix.com>
> In newsgroup: linux.dev.kernel
> > >
> > > and the process running sleep 1000 immediatly returns on Linux. I tested it
> > > on other systems and it works correctly (the sleep continue).
> >
> > Hmm...This works properly on libc5 systems, btw. (glibc2.0 and glibc2.1
> > use nanosleep(), libc5 uses alarm() and sigsuspend()).
> >
>
> It really could be argued what is the right behaviour here. When a
> system call is interrupted by the signal, the normal thing is to
> return EINTR.
>
> -hpa
>

It becomes a definition of BSD_SIGNALS. If I remember correctly,
they, by default, use SA_RESTART as a flag. This way, sleep()
and other system calls automatically restart after a signal. At
the kernel level, any signal delivered to a process, causes a
co-pending system call to return to the caller with -EINTR. It
is the 'C' runtime library that decides, based upon this flag,
if the system call should be restarted or if -1 should be returned
to the caller with errno set to EINTR.

Cheers,
Dick Johnson

Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : The end of the world as we know it requires a new calendar.
Seconds : 2013503 (until Y2K)

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