Date: Wed, 9 Oct 2002 13:31:10 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Juli Mallett <jmallett@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: <Pine.NEB.3.96L.1021009130520.18637C-100000@fledge.watson.org> In-Reply-To: <20021008150324.A47084@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 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:
(1) Avoids the failure modes of signal queues in critical places (i.e.,
termination of a process that is consuming too many resources, such as
in OOM).
(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).
(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.
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.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
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?Pine.NEB.3.96L.1021009130520.18637C-100000>