From owner-freebsd-arch Tue Oct 8 19:16:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C70AF37B401; Tue, 8 Oct 2002 19:16:46 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C00A43E6A; Tue, 8 Oct 2002 19:16:46 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g992GYvU037201; Tue, 8 Oct 2002 19:16:38 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210090216.g992GYvU037201@gw.catspoiler.org> Date: Tue, 8 Oct 2002 19:16:34 -0700 (PDT) From: Don Lewis Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] To: jmallett@FreeBSD.ORG Cc: arch@FreeBSD.ORG In-Reply-To: <20021005002021.A14635@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii 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 On 5 Oct, Juli Mallett wrote: > To > accomodate situations where allocation of a 'ksiginfo' is a failure > mode (no memory), the destination process is told to exit via a new > member of 'struct proc', p_suicide, which tells a process to kill itself > next time it goes through userret. It is done this way to prevent a > recursive failure case, and to prevent possibly dying with extraneous > locks held, as signals are sent from odd places of the kernel. Another problem with p_suicide is that the process exit status will be incorrect. If the process dies because of the receipt of a signal, the exit status should contain the signal number. I like Garrett's suggestion of keeping the bitmap. There's no sense in queuing up information for any signals that will terminate the process before it can retrieve the additional information, whether the signal is uncatchable like SIGKILL, or because the process has not supplied a handler and the default action is to terminate the process. That will prevent kernel memory from being uselessly consumed by a user leaning on ^c in an attempt to kill a process stuck in an uninterruptable wait. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message