This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.7.8-1: Signals do NOT interrupt interruptible calls in threads.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]