Date: Mon, 30 Sep 2002 23:40:52 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Juli Mallett <jmallett@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_sigq.c Message-ID: <Pine.NEB.3.96L.1020930233036.27785C-100000@fledge.watson.org> In-Reply-To: <200210010319.g913Joj3014084@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This seems like an ill-advised change. Please consider backing this
entire set of changes out until these ideas have seen broader review.
Thus far, it seems that:
(1) These changes has not been adequately tested--given that many parts of
the kernel did not compile, there's no way it can have been properly
tested. In addition, you have acknowledged that you did not
understand at least one of the broken cases, the Coda case.
(2) This change introduces new failure modes in low-memory situations,
including potential panics of your pool of signal delivery resources
expires. These failure modes simply were not possible with the old
signal implementation, and given that the signal mechanism is
explicitly used to respond to low-memory conditions (especially in the
VM code), this change is alarming.
(3) It's not clear that these changes can be used to easily support the
POSIX realtime signal semantics, and until we know that they can, the
benefit of the changes is far from clear. Any change to introduce
reliability and queueing properties to our signal implementation
should be done only in the context of an informed decision relating to
portability issues raised in the relevant specifications. Reliable
signalling is not un-trodden ground.
(4) These changes have not seen sufficient broader review by the FreeBSD
developer community. The signalling code is extremely sensitive, and
already left fragile from the KSE commits. The semantics of the
current code are subtle, and any modification risks introducing
substantial problems in signal sensitive applications, such as heavily
threaded linux applications (Java, et al).
This is not to say that the direction you're taking things isn't
potentially a good idea; rather, my concern is that we're not yet ready to
move in that direction without more discussion and testing.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
On Mon, 30 Sep 2002, Juli Mallett wrote:
> jmallett 2002/09/30 20:19:50 PDT
>
> Modified files:
> sys/kern subr_sigq.c
> Log:
> Until I find a way to release arbitrary locks held when sending signals (there
> really should not be some), use the M_NOWAIT flag to malloc(9), and panic(9)
> if malloc(9) fails.
>
> Revision Changes Path
> 1.4 +2 -2 src/sys/kern/subr_sigq.c
>
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.1020930233036.27785C-100000>