From owner-freebsd-arch Tue Oct 8 15: 3:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 2A3D137B401; Tue, 8 Oct 2002 15:03:24 -0700 (PDT) Date: Tue, 8 Oct 2002 15:03:24 -0700 From: Juli Mallett To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <20021008150324.A47084@FreeBSD.org> References: <20021005002021.A14635@FreeBSD.org> <200210051816.g95IGu7K026880@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200210051816.g95IGu7K026880@khavrinen.lcs.mit.edu>; from wollman@lcs.mit.edu on Sat, Oct 05, 2002 at 02:16:56PM -0400 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes 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 * De: Garrett Wollman [ 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. 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. Thanks, juli. -- Juli Mallett | 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