Date: Thu, 7 Apr 2011 16:30:23 +0200
From: Marcin Konarski <huginn78@o2.pl>
To: cygwin@cygwin.com
Subject: Re: 1.7.8-1: Signals do NOT interrupt interruptible calls in threads.
Message-ID: <20110407143023.GA8488@vegeta.utgard.biz>
Mail-Followup-To: cygwin@cygwin.com
References: <20110330115205.GA8867@vegeta.utgard.biz>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
In-Reply-To: <20110330115205.GA8867@vegeta.utgard.biz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On Wed, Mar 30, 2011 at 01:52:05PM +0200, Marcin Konarski wrote:
> Hello list.
> 
> I have a code that depends on calls that are normally interruptible
> by signals to be interrupted by signal delivery also in threads.
> 
> In my installation of cygwin I see that calls are interrupted
> as long as I do not try to run them inside a thread.

Nobody answered so I bothered to get cygwin sources
and look through relevant code parts.

I started with stracing both scenarios:
1) interruptible_call() without threads
2) interruptible_call() in thread

(again, the issue I reported is that in case 2
signals do not interrupt interruptible_call())

I sample program I have posted the call in question was select(),
so I started my investigation with that.

select() as in winsup/cygwin/select.cc:
extern "C" int
cygwin_select (int maxfds, fd_set *readfds, fd_set *writefds, fd_set
*exceptfds, struct timeval *to);

uses signal_arrived Windows Event object as a means for interruption.

This event is fired from:

winsup/cygwin/exceptions.cc:
void __stdcall _cygtls::interrupt_setup (int sig, void *handler, struct sigaction& siga);
static int setup_handler (int sig, void *handler, struct sigaction& siga, _cygtls *tls);
int __stdcall sigpacket::process ();

During strace sessions I see (among others):

for case 1:
60 2755927 [sig] 1exec 3260 _cygtls::find_tls: sig 14
41 2755968 [sig] 1exec 3260 sigpacket::process: signal 14, about to call 0x66CDF0A8
38 2756006 [sig] 1exec 3260 setup_handler: controlled interrupt. stackptr 0x28DB34, stack 0x28DB30, stackptr[-1] 0x66CE7F39

for case 2:
59 2759537 [sig] 1exec 2920 _cygtls::find_tls: sig 14
24 2759561 [sig] 1exec 2920 sigpacket::process: signal 14 blocked
24 2759585 [sig] 1exec 2920 sigpacket::process: returning -1

The difference from those outputs results from the fact that
_cygtls * _cygtls::find_tls (int sig);
ffrom: winsup/cygwin/cygtls.cc

does not find given signal
in sigwait_mask field of any _cygtls object of any thread.

I see in:
winsup/cygwin/thread.cc, and winsup/cygwin/signal.cc,
that neither:
extern "C" int pthread_sigmask (int operation, const sigset_t *set, sigset_t *old_set);
nor
extern "C" int sigprocmask (int how, const sigset_t *set, sigset_t *oldset);
changes the sigwait_mask field of _cygtls,
only sigmask field of _cygtls is modified.

Does anybody have an idea if changing 
_cygtls * _cygtls::find_tls (int sig);
in such a way that it would look through both sigwait_mask and sigmask
fields would solve the issue raised?

Regards.

-- 
  Huginn
GCS d? s: a C++$() UBLS++++$ P++ L++++$ E---
W+(-) N++ w-- O M- V- PS+ PE++ Y PGP-
t--- 5-- X- R !tv b++ DI+++ D+ G e* h r++ y**

--
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