Date: Fri, 11 Oct 2002 06:06:16 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Don Lewis <dl-freebsd@catspoiler.org>, wollman@lcs.mit.edu, arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <20021011060615.B5569@FreeBSD.org> In-Reply-To: <Pine.NEB.3.96L.1021011083203.42071B-100000@fledge.watson.org>; from rwatson@FreeBSD.ORG on Fri, Oct 11, 2002 at 08:37:48AM -0400 References: <200210111218.g9BCIpvU045027@gw.catspoiler.org> <Pine.NEB.3.96L.1021011083203.42071B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* De: Robert Watson <rwatson@FreeBSD.ORG> [ Data: 2002-10-11 ] [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] > 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. That's what top-1.a. was for, and of course we can do this, because if the handler isn't SA_SIGINFO, the second argument is u_long code, not a siginfo_t, ergo all we need to have is traditional-quality code delivery... Which sorta sucks :) > 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. Of course this can be done, too. -- Juli Mallett <jmallett@FreeBSD.org> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! 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?20021011060615.B5569>