Phil Howard <phil-linux-kernel@ipal.net> writes:
|> The accept() call does indeed return errno==ERESTARTSYS to user space
|> when coming back from signal handling, even though other things like
|> poll() return errno==EINTR. This would not really be a problem except
|> for this in include/linux/errno.h starting at line 6:
|>
|> +=============================================================================
|> | #ifdef __KERNEL__
|> |
|> | /* Should never be seen by user programs */
|> | #define ERESTARTSYS 512
|> | #define ERESTARTNOINTR 513
|> | #define ERESTARTNOHAND 514 /* restart if no handler.. */
|> | #define ENOIOCTLCMD 515 /* No ioctl command */
|> +=============================================================================
|>
|> So which way is it _supposed_ to be (so someone can patch things up
|> to make it consistent):
|>
|> 1. User space should never see ERESTARTSYS from any system call
Yes. The kernel either transforms it to EINTR, or restarts the syscall
when the signal handler returns.
|> 2. ERESTARTSYS can be seen from system call and is defined somewhere
|>
|> In user space I have to define __KERNEL__ to get programs to compile
|> when coded to know about all possible (valid?) values of errno from
|> system calls. As seen from strace:
strace is special here, because it gets more information than the traced
program would get.
|> +=============================================================================
|> | [pid 6453] accept(5, 0xbffff908, [16]) = ? ERESTARTSYS (To be restarted)
At this point the accept syscall hasn't actually finished yet, but rather
suspended to let the program execute the signal handler. As soon as the
signal handler returns the syscall will be restarted.
Andreas.
-- Andreas Schwab "And now for something Andreas.Schwab@suse.de completely different." SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 - 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 : Fri Nov 23 2001 - 21:00:30 EST