X-Spam-Check-By: sourceware.org Date: Thu, 23 Feb 2006 16:55:03 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Shells hang during script execution Message-ID: <20060223215503.GB20944@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <20060223214033 DOT GA356 AT trixie DOT casa DOT cgf DOT cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060223214033.GA356@trixie.casa.cgf.cx> User-Agent: Mutt/1.5.11 Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Thu, Feb 23, 2006 at 04:40:33PM -0500, Christopher Faylor wrote: >On Thu, Feb 23, 2006 at 04:33:45PM -0500, Ernie Coskrey wrote: >>There are two hang conditions that we've identified and have developed fixes for. This is a description of the first of the two along with a patch; I'll follow up with a description and patch for the second. >> >> >>If a signal can't be handled because it is blocked, it gets queued (on >>the process's "sigq") to be handled later. Now, whenever the process's >>signal mask changes (e.g., the signal in question gets unblocked), an >>attempt is made to handle all the queued signals (i.e., a signal flush >>occurs). However, if the queueing of the blocked signal happens right >>after the signal mask change, then we miss the signal. This causes the >>process to hang. The signal is on the queue, but the process doesn't >>know to check for it. The process just hangs until another signal gets >>sent to it. >> >>The workaround is basically to force the signal queue to be rescanned >>(flushed) whenever we add something to it, so a queued signal is never >>missed. > >Thanks for the analysis and the patch. > >But, a backwards goto into a case? Yuck. I'll see if I can come up >with something better. Actually, I spoke too soon. I don't understand your analysis. You make this statement: >>However, if the queueing of the blocked signal happens right after the >>signal mask change, then we miss the signal. but I don't understand how you came to this conclusion. If the signal mask changes, then the queue should be flushed -- that's what the __SIGFLUSH is for. So, even if something is added to the queue while the mask is changing, the function which changes the mask should eventually call send_sig to cause the wait_sig thread to run the queue. So, this patch would seem to be a band-aid over some other problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/