Date: Fri, 11 Oct 2002 05:18:51 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: jmallett@FreeBSD.ORG Cc: rwatson@FreeBSD.ORG, wollman@lcs.mit.edu, arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <200210111218.g9BCIpvU045027@gw.catspoiler.org> In-Reply-To: <20021011030328.A92175@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 Oct, Juli Mallett wrote: > * De: Robert Watson <rwatson@FreeBSD.org> [ Data: 2002-10-09 ] >> Signal queues involve failures. If at all possible, I'd like us to use a >> strategy that: >> >> (2) Avoids the failure modes of signal queues in situations where access >> to the signal data is not critical (i.e., if the receiving process >> isn't requesting information on signals, don't store it -- I don't >> know if the POSIX API supports this semantic though). The Solaris man page for sigqueue() doesn't specifically say what happens in this case, but it implies that just setting a signal bit on the target process is one of the possibilities. > I'm playing with an idea in my head such that: > in a signal queuer/sender(not sendsig, that's really md_postsig -- it posts > a signal), > 1. signal_add is called. > a. Does this signal have an SA_SIGINFO handler? > I. Were we given a ksiginfo to queue? > 1. Allocate one... Does that fail? > a. Invoke an OOM killer, or such. Solaris returns an EAGAIN to the caller and the target is unaffected. If the caller really wants to nuke the target, it could retry with kill(). The same error will be returned if there are too many signals in the target's queue, which should prevent the signal queue for a wedged process from consuming all of kmem. > : > a. Continue. > : > 1. Enqueue it! > : > I. Add it to the bitmask. > > > And I'd resurrect the bitmask for plain signals, but I'd put all the > operations inside wrapped versions in subr_sigq, so that the higher-level > has no idea what is going on. 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?200210111218.g9BCIpvU045027>