Date: Fri, 11 Oct 2002 03:03:28 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Garrett Wollman <wollman@lcs.mit.edu>, arch@FreeBSD.org Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <20021011030328.A92175@FreeBSD.org> In-Reply-To: <Pine.NEB.3.96L.1021009130520.18637C-100000@fledge.watson.org>; from rwatson@FreeBSD.org on Wed, Oct 09, 2002 at 01:31:10PM -0400 References: <20021008150324.A47084@FreeBSD.org> <Pine.NEB.3.96L.1021009130520.18637C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* De: Robert Watson <rwatson@FreeBSD.org> [ Data: 2002-10-09 ] [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] > On Tue, 8 Oct 2002, Juli Mallett wrote: > > > * De: Garrett Wollman <wollman@lcs.mit.edu> [ Data: 2002-10-05 ] > > [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] > > > >The most notable change is that the most recently sent && lowest > > > >numbered signal is sent, in the normal course of events, rather than > > > >simply the lowest numbered or most recently sent. > > > > > > This still isn't right. Real-time signals are QUEUED -- i.e., signals > > > of the same species are delivered in FIFO, not LIFO, order. POSIX > > > further specifies that signal N will be delivered before signal N+k, > > > for SIGRTMIN <= N <= N+k <= SIGRTMAX. The relative delivery order of > > > any signals outside of this range is unspecified beyond the special > > > behavior of SIGCONT, SIGSTOP, and SIGKILL. > > > > OK, I'm reading through this stuff extensively. There's a number of > > kernel interfaces that I'd like to add, related to them, but first thing > > is to get the queueing in there, IMHO, so that the base functionality is > > there to be built on. sigqueue() for example is about 10LOC with this > > stuff, and adding 'si_errno' stuff (which I'll love to have around) is > > just a matter of 4 lines of code wherever it can be used, once I've > > added a supportable in-kernel abstraction of psignal that takes a ksi, > > and does the normal sanity checks. > > > > That will make psignal about 12LOC, given that there's about 2LOC more > > than sigqueue() needed, as most of that is allocation and filling out a > > structure. > > Lines of code is not a good measure of complexity, especially when what > you're doing is moving and introducing complexity in other bits of the > code. I appreciate that this improves the abstractions some, but > psignal() is actually not all that terrible. Actually, in this case, it's more than that. It's expository with regard to the fact that this abstracts a few existing things, and further, it makes it actually possible to get a siginfo_t to/from somewhere. This is more or less impossible to do right with the current code. > > So assuming the FIFO behaviour is fixed, and that I also deliver the > > lowest available signal, and given that I plan to implement the above, > > do you have ny further objections? > > > > Other than the issue of the bitmask, which I see no easy and reliable > > method for getting around cleanly... And the failure cases. Would you > > settle for me using subr_sigq.c as my abstraction, and making actual > > queues optional, and having it use sigset_t under certain circumstances? > > It will add about 8LOC to every sendsig() to support pulling out the > > information when no ksiginfo is around. > > 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). 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. : 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. > (3) Leaves the failure mode semantics up to the caller, so that the caller > can decide if the signal delivery attempt is something worth retrying > or just ignoring. The Linux behavior I looked at (and told you > about) is that the actual signal queueing routines return EAGAIN if > the slab allocation fails, permitting the caller to retry if it wants, > or more likely, simply drop the signal. I believe this is how Linux > handles slab allocator failures for things like SIGIO, SIGCHLD, etc. Along with the above, would returning EAGAIN satisfy you? > In terms of strategy for supporting a changed to queued signals, my > recommendation would be that you go ahead and implement the POSIX realtime > signals based on your structural changes in a local tree and make sure the > structural changes end up doing what you need. Then present the whole > bundle as one big patch on arch@, along with an indication of how the > elements of the commit relate. I'm doing this in the jmallett_hack branch in Perforce now, so others will have access to this, and so I don't have to lug around patch files, or 10 different local CVS repositories. This stuff is too low-impact to warrant that for me. As for the further implementation, I'm going to look at sigqueue() and friends soon. I read the whole of the specs the other day, and it cleared up a good number of my concerns, and also gave me a handful of good ideas. I will go back over them some time soon, and have a go at implementing some of the more basic signal queue/rts interfaces. I want to lay groundwork, something to build on in the future. I'm also very concerned that we have siginfo_t in the kernel right now, but it's always a lie, bogus, etc., and pretty much has no business being there. Sound OK? Thanks, juli. -- 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?20021011030328.A92175>