Date: Sat, 5 Oct 2002 19:08:06 -0700 From: Alfred Perlstein <bright@mu.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: <20021006020806.GV95327@elvis.mu.org> In-Reply-To: <20021005113333.A56357@FreeBSD.org> References: <20021005002021.A14635@FreeBSD.org> <200210051816.g95IGu7K026880@khavrinen.lcs.mit.edu> <20021005113333.A56357@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Juli Mallett <jmallett@FreeBSD.org> [021005 11:33] 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, well, then it's a matter of :s/_INSERT_HEAD/_INSERT_TAIL/. As for > only doing this for RTS, we'd have to duplicate large portions of the > signal code, and sendsig stuff, and have two seperate interfaces. > > > Please read section 2.4 of the System Interfaces volume of IEEE > > Std.1003.1-2001 very carefully before proceeding. If you do not have > > a copy of the standard, I think Mike Barcroft still has a few copies > > of The Open Group's ``authorized guidebook'' which includes a CD-ROM > > of the full standard. > > I have one of those, and I meant to stuff it on our fileserver and move > the appropriate data into our books directory. Haven't yet. I suck. 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. 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'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. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' 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?20021006020806.GV95327>