Date: Mon, 30 Sep 2002 19:55:47 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Juli Mallett <jmallett@FreeBSD.org> Cc: Julian Elischer <julian@elischer.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/osf1 osf1_signal.c Message-ID: <Pine.NEB.3.96L.1020930194909.15622Y-100000@fledge.watson.org> In-Reply-To: <20020930162948.A50424@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Sep 2002, Juli Mallett wrote: > * De: Julian Elischer <julian@elischer.org> [ Data: 2002-09-30 ] > [ Subjecte: Re: cvs commit: src/sys/alpha/osf1 osf1_signal.c ] > > On Mon, 30 Sep 2002, Juli Mallett wrote: > > > > > > > > I should mention that signal delivery is now decidedly almost LIFO, and > > > will be fully LIFO once everything uses a ksiginfo, and not a signal > > > number... Right now it's almost racey, which leaves it undefined, but > > > it's mostly like... [keep in mind the proc lock must be held, so there > > > is no race, and it is defined, but...] > > > 1. Check the signal queue... > > > 2. Pop a signal number off... The most recently recv'd... > > > 3. Dequeue the first signal we find with that signo... > > > 4. Send it... > > > > IF IT'S A tailq, why isn't it FIFO? > > would it make a difference to have one queue per type? > > Because you want the most immediate thing, think about recieving SIGSTOP > while you have other signals queued. I'm not a big standards person, but I think that if we're going to work on reliable signal delivery, we need to do it in the context of the existing specifications and behaviors. As with Julian, I'm a little queasy about LIFO, but don't really have enough background to say what "right" or "wrong" might mean. For example, I know that POSIX talks about using signals to deliver AIO completion information to the process context--does POSIX make any assertions about delivery order for those events? Likewise, for job control: job control generally assumes that the events generated by the user are processed in the order the user generated them. We already have several classes of signal behavior: some signals are flags as conditions on the process and delivered later, others result in a more immediate affect on process scheduling or behavior. Maybe in moving this thread to arch@, could you talk about how other systems handle this behavior, and any standards requirements that affect this work? 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 cvs-all" 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.1020930194909.15622Y-100000>