|> Hi,
|> could somebody enlighten me? According to POSIX.1 the following
|> program should exit with status 0:
[...]
|> But when I run this program I get (using strace):
|> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|> [...]
|> personality(PER_LINUX) = 0
|> sigaction(SIGALRM, {0x8048970, [], 0}, NULL) = 0
|> pipe([3, 4]) = 0
|> fcntl(3, F_GETFL) = 0 (flags O_RDONLY)
|> brk(0) = 0x804ac7c
|> brk(0x804acfc) = 0x804acfc
|> brk(0x804b000) = 0x804b000
|> fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
|> brk(0x804d000) = 0x804d000
|> lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
|> alarm(2) = 0
|> read(3, 0x804acf8, 4096) = ? ERESTARTSYS (To be restarted)
|> --- SIGALRM (Alarm clock) ---
|> sigreturn() = ? (mask now [])
|> read(3, <unfinished ...>
|> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|> I used C-c to teerminate the process. Why does read() does not return
|> with errno set to EINTR?
Tracing a program changes the behaviour of interruptable syscalls. This
should be fixed in the kernel sometime, but it is difficult because the
context of the interrupted syscall is lost after the debugger has been
called. I tried to get it right in Linux/m68k, but i didn't succeed. The
GDB testsuite is a good place to find the difficult parts.
So actually read() does return EINTR, but only when not tracing.
Andreas.
-- Andreas Schwab "And now for something schwab@issan.informatik.uni-dortmund.de completely different"