Messages in this thread | | | Date | Wed, 8 Dec 1999 16:41:37 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: SIGCONT misbehaviour in Linux |
| |
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/
| |