From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p747rZL3054416 for ; Thu, 4 Aug 2011 02:53:36 -0500 Date: Thu, 4 Aug 2011 03:53:31 -0400 From: Christoph Hellwig Subject: Re: [PATCH 4/4] xfsdump: convert to the POSIX signal API Message-ID: <20110804075331.GA8836@infradead.org> References: <1311972011-1446-1-git-send-email-wkendall@sgi.com> <1311972011-1446-5-git-send-email-wkendall@sgi.com> <20110803104813.GA3575@infradead.org> <4E393AE3.70505@sgi.com> <20110803123934.GA13447@infradead.org> <4E39A176.7000906@sgi.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4E39A176.7000906@sgi.com> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Bill Kendall Cc: Christoph Hellwig , xfs@oss.sgi.com On Wed, Aug 03, 2011 at 02:28:54PM -0500, Bill Kendall wrote: > Here's some background explaining why things are done as they > are now, from my understanding of the code. > > The regular handler won't acquire a lock. The signal handler is > replaced because the rules are different when receiving a signal > while in a dialog. For instance, SIGINT normally means interrupt > the dump session, but in a dialog we just return a caller-supplied > value indicating the interrupt. > > When a dialog is required, the caller does this: > > dlog_begin(); // grabs mlog_lock > dlog_*_query(); // ends up in promptinput() > dlog_end(); // releases mlog_lock > > I think the purpose of holding the lock is simply to prevent > other output on the terminal while waiting for a response. Ok, that makes some sense. > Any thread may issue a dialog, and it's possible that while > a thread is sitting in a dialog, the main thread may try to > log a message (e.g., progress report) and get blocked on the > mlog lock. At this point nobody would be able to handle signals -- > the main thread blocks all signals except while in sigsuspend, > and other threads always block signals. So we unblock the > signals in the current thread to ensure some thread is available > to handle them. Unblocking the signals during the dialog, but still using the normal signal handler for it would solve that problem, right? Btw, I looked over the main sighandler a bit, and it seems like most of it can simply go away for a pthreaded variant - there is no need to handle SIGCLD, and all threads have the same pid, so basically what is left is SIGHUP/SIGTERM/SIGINT/SIGQUIT handling, which does nothing but a dlog_desist in most cases and setting the sigfoo_received variable. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs