[lkml]   [1999]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SIGCONT misbehaviour in Linux
On Wed, 8 Dec 1999, Andrea Arcangeli wrote:

> On Wed, 8 Dec 1999, Richard B. Johnson wrote:
> >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.
> glibc could also return to run the syscall without waiting again from the
> beginning by looking at the 'struct timespec *rem'. If there wouldn't be
> the `rem` parameter in nanosleep, glibc couldn't wrap the -EINTR
> trasparently. But there is.
> NOTE: I can as well fix the kernel for this, but I agree with Peter that
> returning -INTR looks like the right thing to do. (I don't know which is
> the official semantic for the syscall though)
> Andrea
I think the kernel provides the correct result. The caller either has
to use '_BSD_SIGNALS_' or use code like this:

#include <stdio.h>
#include <signal.h>
#include <errno.h>
#include <string.h>

void foo(int unused) { puts("\7Alarm"); }

main(int x)
struct sigaction sa;
char buf[1];
int i;
memset(&sa, 0x00, sizeof(sa));
if(x > 1)
sa.sa_flags = SA_RESTART;
sa.sa_handler = foo;
sigaction(SIGALRM, &sa, NULL);
i = read(0, buf, 1);
printf("%d, %s\n", i, strerror(errno));

Depending upon whether anything is on the command-line, the SA_RESTART
flag is set. This allows one to get both kinds of behavior with no
problems. I think the kernel code is correct.

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 : 2010151 (until Y2K)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.057 / U:11.572 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site