Mail Archives: cygwin/2011/04/14/14:32:18
X-Recipient: | archive-cygwin AT delorie DOT com
|
X-SWARE-Spam-Status: | No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_YG,T_TO_NO_BRKTS_FREEMAIL
|
X-Spam-Check-By: | sourceware.org
|
MIME-Version: | 1.0
|
In-Reply-To: | <20110407143023.GA8488@vegeta.utgard.biz>
|
References: | <20110330115205 DOT GA8867 AT vegeta DOT utgard DOT biz> <20110407143023 DOT GA8488 AT vegeta DOT utgard DOT biz>
|
Date: | Thu, 14 Apr 2011 19:32:07 +0100
|
Message-ID: | <BANLkTimtW_SMkvHcDDjGfq22S5Q7xbNbyA@mail.gmail.com>
|
Subject: | Re: 1.7.8-1: Signals do NOT interrupt interruptible calls in threads.
|
From: | Andy Koppe <andy DOT koppe AT gmail DOT com>
|
To: | cygwin AT cygwin DOT com
|
X-IsSubscribed: | yes
|
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm
|
List-Id: | <cygwin.cygwin.com>
|
List-Unsubscribe: | <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
|
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com>
|
List-Archive: | <http://sourceware.org/ml/cygwin/>
|
List-Post: | <mailto:cygwin AT cygwin DOT com>
|
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
|
Sender: | cygwin-owner AT cygwin DOT com
|
Mail-Followup-To: | cygwin AT cygwin DOT com
|
Delivered-To: | mailing list cygwin AT cygwin DOT com
|
2011/4/7 Marcin Konarski:
> 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?
I don't know, and the core Cygwin developers appear to be away or too
busy. Have you tried it?
Andy
--
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
- Raw text -