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>