Date: Wed, 4 Apr 2001 21:13:03 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Jonathan Graehl <jonathan@graehl.org> Cc: Freebsd-Net <freebsd-net@freebsd.org>, Jonathan Lemon <jlemon@freebsd.org> Subject: Re: please document that kevent does not automatically restart when interrupted by signals Message-ID: <20010404211303.I70724@prism.flugsvamp.com> In-Reply-To: <NCBBLOALCKKINBNNEDDLEEKNDNAA.jonathan@graehl.org> References: <NCBBLOALCKKINBNNEDDLEEKNDNAA.jonathan@graehl.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 04, 2001 at 05:59:53PM -0700, Jonathan Graehl wrote: > It is my understanding that an unmasked signal will always interrupt a call to > kevent, even if SA_RESTART is specified in sigaction, or siginterrupt(signo, 0) > is used. Yes. > Can this be officially documented so that it can be relied upon? I want signals > to interrupt kevent; I would like to be able to use SA_RESTART so that I don't > have to check for an EINTR except from kevent, but I wouldn't want kevent > restarted for me should the implementation change out from under me. From the sigaction(2) manual page: If a signal is caught during the system calls listed below, the call may be forced to terminate with the error EINTR, the call may return with a data transfer shorter than requested, or the call may be restarted. Restart of pending calls is requested by setting the SA_RESTART bit in sa_flags. The affected system calls include open(2), read(2), write(2), sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications channel or a slow device (such as a terminal, but not a regular file) and during a wait(2) or ioctl(2). However, calls that have already committed are not restarted, but instead return a partial success (for example, a short read count). My interpretation of this is that only the above system calls will allow SA_RESTART to restart an interrupted call. However, the list above seems to be incomplete. kevent (and signal, and poll) will not automatically restart, regardless of the setting of SA_RESTART. The same is true for nanosleep, connect, aio_suspend, and aio_waitcomplete. This short list was obtained by looking at the source, I'm not aware of any place where all these calls are listed. > Other signal interrupt / restart questions: > > Can a signal ever interrupt a (nonblocking) datagram write/read (possibly > truncating a datagram due to a partial read/write count)? (my guess: not unless > you're sleeping awaiting a datagram with a blocking read) Is this behavior > documented? > > Can a signal ever interrupt an I/O on a nonblocking fd, such that the I/O will > return EINTR rather than EAGAIN or a partial success? (my guess: no, I don't > need to check for EINTR for nonblocking fds even if I siginterrupt(signo, 1)) > Is this documented? EINTR should (as far as I know) only be returned if a signal interrupts the syscall when it was in the middle of a sleep. If you are doing non-blocking I/O, then the system should not be sleeping, so EINTR should never be returned. No, I don't think that this is explicitly laid out anywhere in the manual pages, though. > I currently use SA_RESTART, assume that EINTR will never be returned, except I > expect EINTR to be returned immediately by kevent so I can get my signal and > process it in a synchronous fashion outside of my event handling logic. Relying > on undocumented behavior makes me nervous. Are there any other system calls I > should worry about returning EINTR even when I specify SA_RESTART? Other than the short list I gave above, I don't think so. But again, I don't think this is documented anywhwere. Perhaps someone else wants to chime in here? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010404211303.I70724>