[Top] [All Lists]

Re: [PATCH 4/4] xfsdump: convert to the POSIX signal API

To: Bill Kendall <wkendall@xxxxxxx>
Subject: Re: [PATCH 4/4] xfsdump: convert to the POSIX signal API
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 4 Aug 2011 03:53:31 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4E39A176.7000906@xxxxxxx>
References: <1311972011-1446-1-git-send-email-wkendall@xxxxxxx> <1311972011-1446-5-git-send-email-wkendall@xxxxxxx> <20110803104813.GA3575@xxxxxxxxxxxxx> <4E393AE3.70505@xxxxxxx> <20110803123934.GA13447@xxxxxxxxxxxxx> <4E39A176.7000906@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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

<Prev in Thread] Current Thread [Next in Thread>