Date: Mon, 7 Dec 2009 11:35:47 -0500
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.0: question about signal delivery to pthreads
Message-ID: <20091207163547.GB12309@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4B1D2338 DOT 2050509 AT cell-active DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B1D2338.2050509@cell-active.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Mon, Dec 07, 2009 at 04:46:00PM +0100, Karsten Otto wrote:
>Hi everybody!
>
>I have a question regarding the delivery of signals to pthreads in 
>Cygwin (1.7 beta). As an example, please consider the following 
>situation (see attached file for source code):
>
>There are two threads, a main thread and another one created by the main 
>thread.
>The main registers a SIGALRM signal handler (sigaction), creates the 
>other thread (pthread_create), blocks all signals (pthread_sigmask), 
>then waits for a SIGHUP (sigwait) before joining the other thread 
>(pthread_join).
>The other thread unblocks all signals (pthread_sigmask), then schedules 
>an alarm (alarm(1)) and goes to sleep (sleep(5)).
>
>In this situation, I had expected the other thread to receive the 
>SIGALRM, and to wake up from sleep consequently; at least it did in 
>Linux (2.6.31). However, in Cygwin the signal never arrives, the thread 
>sleeps the full turn.
>
>It seems the signal gets delivered to the blocked main thread instead, 
>but attempting to check (sigpending) results in a segmentation fault 
>(SEGV) for some reason.
>
>If I explictly remove the SIGALRM from the block mask, the signal 
>handler gets called and sigpending works, but of course this interrupts 
>sigwait (errno=EINTR), hence this is not a viable workaround for me.
>
>So, is cygwin behaving correctly here (in a POSIX sense), or is this a 
>bug? Please help me understand.

I can't check this right now but I will when I get back to a convenient
windows system.

If it is a cygwin bug it is not likely to be fixed for a while since
the official release of Cygwin 1.7 is imminent.  So it will have to wait
for 1.7.2.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple