From owner-cvs-all Mon Sep 30 20:41:22 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A724F37B401; Mon, 30 Sep 2002 20:41:20 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9380043E8A; Mon, 30 Sep 2002 20:41:19 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g913erOo028345; Mon, 30 Sep 2002 23:40:53 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 30 Sep 2002 23:40:52 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Juli Mallett Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_sigq.c In-Reply-To: <200210010319.g913Joj3014084@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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