From owner-freebsd-arch Fri Oct 11 6: 6:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 147AD37B401; Fri, 11 Oct 2002 06:06:16 -0700 (PDT) Date: Fri, 11 Oct 2002 06:06:16 -0700 From: Juli Mallett To: Robert Watson Cc: Don Lewis , 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> References: <200210111218.g9BCIpvU045027@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rwatson@FreeBSD.ORG on Fri, Oct 11, 2002 at 08:37:48AM -0400 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * De: Robert Watson [ 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 | 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