From owner-freebsd-arch Sat Oct 5 19:20:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 7906437B401; Sat, 5 Oct 2002 19:20:12 -0700 (PDT) Date: Sat, 5 Oct 2002 19:20:12 -0700 From: Juli Mallett To: Alfred Perlstein Cc: Garrett Wollman , arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <20021005192012.A87801@FreeBSD.org> References: <20021005002021.A14635@FreeBSD.org> <200210051816.g95IGu7K026880@khavrinen.lcs.mit.edu> <20021005113333.A56357@FreeBSD.org> <20021006020806.GV95327@elvis.mu.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: <20021006020806.GV95327@elvis.mu.org>; from bright@mu.org on Sat, Oct 05, 2002 at 07:08:06PM -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: Alfred Perlstein [ Data: 2002-10-05 ] [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] > You've done a lot of very good work. I'd also like to thank Garrett for > taking the time to do the standards digging. Yeah, Garrett's great for keeping us from being lazy by letting us be just lazy enough to have to do some real work :) > That said I'm concerned that you haven't addressed the issue of the > signal bitmask, basically being unable to send a non-siginfo style > signal shouldn't fail because of lack of memory. I'm wondering if > this is actually an issue or not, please pardon me for not UTSL'ing > as of yet if it is taken care of. I've been talking with rwatson about a number of possibilities. The idea I like best so far is to just send a fake kernel-originated (as far as the siginfo_t says) signal for each signal that can be sent, e.g. static struct ksiginfo nullsig[NSIG]; (in a SYSINIT) bzero(&nullsig, sizeof nullsig); for (i = 0; i < NSIG; i++) nullsig[i].ksi_signo = i; (if we fail allocation) *ksip = &nullsig[signo]; Robert has pointed out a number of other possibilites, particular with regards to just disregarding the signal, and letting the upper layer decide if it should be re-sent... Both of us are looking into this... Right now I think it may end up being a combination of methods, possibly adding some new facilities in the kernel like an OOM killer, where an app can be flagged (by root) as non-killable in the OOM kase... And sending SIGNOMEM to apps which have installed handlers for it, so that they can free optional resources, if they are so inclined, etc. > I'm not sure if this is feasable but it would seem like having a > bitmask for RTS and non-RTS might work, with the special case being > deqeueing the siginfo when it shows up in the RTS mask. I prefer a generalised approach to all signals, especially since SunOS (ok, Solaris) sends "sender" information for all signals (istr), and that furthermore SIGCHLD contains information about what child died. Very useful stuff, IMO. Thanks, juli. -- 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