From owner-freebsd-arch Fri Oct 11 5:37:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 2F0AA37B401; Fri, 11 Oct 2002 05:37:20 -0700 (PDT) Date: Fri, 11 Oct 2002 05:37:20 -0700 From: Juli Mallett To: Don Lewis 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: <20021011053720.A2431@FreeBSD.org> References: <20021011030328.A92175@FreeBSD.org> <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: <200210111218.g9BCIpvU045027@gw.catspoiler.org>; from dl-freebsd@catspoiler.org on Fri, Oct 11, 2002 at 05:18:51AM -0700 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: Don Lewis [ Data: 2002-10-11 ] [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] > On 11 Oct, Juli Mallett wrote: > > * De: Robert Watson [ 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'd really really rather avoid that, but I'm not wholly opposed to it. > > 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. Uhm, not really. Retrying with SIGKILL won't result in the signal being queued. -- 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