From owner-freebsd-arch Fri Oct 11 6:20:10 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 772CA37B401; Fri, 11 Oct 2002 06:20:09 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01CB743E88; Fri, 11 Oct 2002 06:20:09 -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 g9BDJxvU045210; Fri, 11 Oct 2002 06:20:03 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210111320.g9BDJxvU045210@gw.catspoiler.org> Date: Fri, 11 Oct 2002 06:19:59 -0700 (PDT) From: Don Lewis Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] To: jmallett@FreeBSD.ORG Cc: rwatson@FreeBSD.ORG, wollman@lcs.mit.edu, arch@FreeBSD.ORG In-Reply-To: <20021011053720.A2431@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 11 Oct, Juli Mallett wrote: > * De: Don Lewis [ Data: 2002-10-11 ] >> Solaris returns an EAGAIN to the caller and the target is unaffected. If >> the caller really wants to nuke the target, it could retry with kill(). >> The same error will be returned if there are too many signals in the >> target's queue, which should prevent the signal queue for a wedged >> process from consuming all of kmem. > > Uhm, not really. Retrying with SIGKILL won't result in the signal being > queued. The sender may be periodically sending SIGUSR1 in a loop to wake up an associated process. If the other process is stuffed up, then the sender will eventually find out when the target's queue fills up. It can then use kill(), or take whatever other action is appropriate. Have you never been blessed with a process stuck in an un-interruptable wait that even SIGKILL won't touch? It's a real PITA when this happens to a process on THE VERY IMPORTANT SERVER that happens to have a file descriptor open on the only tape drive. The only way to unwedge things is to reboot. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message