Date: Thu, 6 Jun 2002 06:43:03 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: netchild@FreeBSD.ORG, <audit@FreeBSD.ORG>, <bhlewis@wossname.net> Subject: Re: [PATCH] making dump EINTR resistant Message-ID: <20020606063157.V8685-100000@gamplex.bde.org> In-Reply-To: <200206050819.g558JnPP000786@Magelan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Jun 2002, Alexander Leidinger wrote: > On 5 Jun, Bruce Evans wrote: > > read(), etc., are supposed to be restarted after signals, so the EINTR > > checks should have no effect in most cases. > > Yes, I wanted to handle it with sigaction & SA_REASTART, but the APUE > book teached me, that signal(3) does restart interrupted syscalls by > default on 4.3(+)BSD. Therefore I handled it with do-while code. > > Stevens lists only ioctl, read, readv, write, writev, wait and waitpid, > but not open, fopen, close and fclose. What about those? Stevens is correct, but in practice open() and close() often ignores signals while it is in the kernel, so signal delivery occurs when the process is about to leave the kernel and doesn't result in the syscall returning EINTR. I think this (no EINTR) happens for regular files and disk devices. It doesn't happen for slow devices like terminals, and shouldn't happen if the syscall can block (then the device driver must support the syscall being aborted by a signal). fopen() and fclose() are based on open() and close(), and hopefully don't make any other syscalls that could affect this. (POSIX more or less specifies no surprises here.) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020606063157.V8685-100000>