Date: Fri, 11 Oct 2002 08:37:48 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Don Lewis <dl-freebsd@catspoiler.org> Cc: jmallett@FreeBSD.ORG, wollman@lcs.mit.edu, arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <Pine.NEB.3.96L.1021011083203.42071B-100000@fledge.watson.org> In-Reply-To: <200210111218.g9BCIpvU045027@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Oct 2002, Don Lewis wrote: > > 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. Agreed. I think it would be best if the signal code itself didn't kill processes (Well, with the exception of cases where it is supposed to :-) to reclaim resources. Or, if that's the best place to put it, the caller should definitely be able to indicate its disposition with regards to failure modes. The temptation would be (assuming this was feasible): 1 If the target isn't doing anything special for the signal, don't pay the price of reliable delivery. 2 If the target is doing something special for the signal, allow the code attempting to deliver the signal figure out what to do if it fails. I know that (2) is possible, because Linux does that. I don't know much/anything about (1), but the conversation seems suggestive that that is possible. I'd be comfortable with this route as the experimental direction to see how well it all pulls together in the Perforce branch. However, for each case where we're considering (2) for a kernel generated signal, we need to determine what (if any) failure mode is appropriate. That would probably take looking at the specs closely, looking at other implementations, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories 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?Pine.NEB.3.96L.1021011083203.42071B-100000>