Date: Fri, 11 Oct 2002 05:37:20 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: Don Lewis <dl-freebsd@catspoiler.org> 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> In-Reply-To: <200210111218.g9BCIpvU045027@gw.catspoiler.org>; from dl-freebsd@catspoiler.org on Fri, Oct 11, 2002 at 05:18:51AM -0700 References: <20021011030328.A92175@FreeBSD.org> <200210111218.g9BCIpvU045027@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* De: Don Lewis <dl-freebsd@catspoiler.org> [ 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 <rwatson@FreeBSD.org> [ 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 <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?20021011053720.A2431>