From owner-freebsd-arch Fri Oct 11 5:28:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7672837B401; Fri, 11 Oct 2002 05:28:54 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD2F843EA9; Fri, 11 Oct 2002 05:28:53 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g9BCIpvU045027; Fri, 11 Oct 2002 05:18:55 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210111218.g9BCIpvU045027@gw.catspoiler.org> Date: Fri, 11 Oct 2002 05:18:51 -0700 (PDT) From: Don Lewis Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] To: jmallett@FreeBSD.ORG Cc: rwatson@FreeBSD.ORG, wollman@lcs.mit.edu, arch@FreeBSD.ORG In-Reply-To: <20021011030328.A92175@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii 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 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'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. > : > a. Continue. > : > 1. Enqueue it! > : > I. Add it to the bitmask. > > > And I'd resurrect the bitmask for plain signals, but I'd put all the > operations inside wrapped versions in subr_sigq, so that the higher-level > has no idea what is going on. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message