X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,TW_YG,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Date: Thu, 7 Apr 2011 16:30:23 +0200 From: Marcin Konarski To: cygwin AT cygwin DOT 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 AT cygwin DOT com References: <20110330115205 DOT GA8867 AT vegeta DOT utgard DOT 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) X-O2-Trust: 2, 60 X-O2-SPF: neutral X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: 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 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