Date: Fri, 11 Oct 2002 06:19:59 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: jmallett@FreeBSD.ORG Cc: rwatson@FreeBSD.ORG, wollman@lcs.mit.edu, arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <200210111320.g9BDJxvU045210@gw.catspoiler.org> In-Reply-To: <20021011053720.A2431@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 Oct, Juli Mallett wrote: > * De: Don Lewis <dl-freebsd@catspoiler.org> [ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210111320.g9BDJxvU045210>