Date: Tue, 8 Oct 2002 20:00:11 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: jmallett@FreeBSD.ORG Cc: bright@mu.org, wollman@lcs.mit.edu, arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <200210090300.g9930BvU037277@gw.catspoiler.org> In-Reply-To: <20021005192012.A87801@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Oct, Juli Mallett wrote: > I prefer a generalised approach to all signals, especially since SunOS > (ok, Solaris) sends "sender" information for all signals (istr), and > that furthermore SIGCHLD contains information about what child died. In Solaris it looks like the "sender" information is only sent if the sender is using sigqueue() and the target has set the SA_SIGINFO flag for the signal. If the target has not set SA_SIGINFO, it looks like sigqueue() behaves like kill() and probably just sets a flag. Also, if the target has set SA_SIGINFO, sigqueue() can fail with EAGAIN if the target has more than a certain number of queued signals pending or of the system is out of resources. It looks like if the sender of the signal used kill() that the only valid information in the siginfo structure may be the signal number. This is a lot easier to implement than a more general scheme, since sigueue is a syscall so the locking and resource allocation issues should be a lot easier to deal with, as opposed to having to deal with these issues in all the other places in the kernel that send signals. SIGCHLD can cheat and peek at the list of zombies. > Very useful stuff, IMO. Yup, it can be. It would also sometimes be useful to know which file descriptor was responsible for a SIGIO, but that would be really nasty on the kernel side ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210090300.g9930BvU037277>