X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=0.7 required=5.0 tests=AWL,BAYES_20,T_RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
X-Spam-CYBERTRENCH-Report:	SpamAssassin 3.2.1-gr2 (2007-05-02) on cybertrench.com hits: -0.1 of 7.0 Bayes: memorize=no score=0.5000 * -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% * [score: 0.5000] * 1.1 DNS_FROM_OPENWHOIS RBL: Envelope sender listed in bl.open-whois.org. * 0.5 AWL AWL: From: address is in the auto white-list
X-Spam-CYBERTRENCH-Level:	-0.1
X-cybertrench.com-virus-scan:	clean
Date:	Tue, 13 Jul 2010 22:02:57 +0200
From:	Corvus Corax <corvuscorax AT cybertrench DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: pthread_mutex_lock doesn't interrupt
Message-ID:	<20100713220257.7b913f2b@CorvusMC.home>
In-Reply-To:	<AANLkTimGXX8Jm3gkbrx25p6mWQj2EitAKqFSs_L8loFz@mail.gmail.com>
Mime-Version:	1.0
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

> Signal generation and signal delivery aren't the same thing. With
> asynchronous signals as in your test case, there's always some sort of
> delay until the signal is delivered, and I don't know whether the
> standard actually requires any upper bound on that. One example where
> a signal in Cygwin gets deferred is when your thread happens to be
> blocked in a Win32 function (although of course POSIX doesn't apply to
> that anyway).
> 
> Having said all that, if it works in Linux, it ought to work in
> Cygwin. No idea what the issue could be though.

Well as you already said, it could be calling a win32 api function to
implement the mutex_lock and miss the signal because of that.

for that I actually might have a work around - a busy loop with

> while (0!=mutex_trylock()) sched_yield();

You must agree though that's a damn ugly solution just to lock a mutex
in a non signal-blocking way. Busy loops are a no brainer. And due to
other bugs with signaling in combination to sched_yield() as in the
other test case - this isn't even stable right now.

However even pselect() with its sigmask argument explicitly
sigemptyset()-ed does completely block signals and doesn't execute the
handler.

pselect() allows the user to specify which signals should be deferred
until the end of pselect() and which should be handled and end
pselect() with errno=EINTR -- and of course also call the signal
handler.

I suspect the reason of this behaviour on the entire group of blocking
functions I found (select(), pselect(), pthread_mutex_lock(), ...)
could possibly be the same.

I haven't found any information about how long signals may be deferred
by POSIX functions without explicit definition of signal blockage.

However POSIX usually explicitly defines the functions which may defer
signals - and in many cases even introduces a mask to control that
behaviour. I think it's a safe assumption however that if a signal is
received and a signal handler is set up, the signal handler shall
EVENTUALLY be called unless specified otherwise.

With pthread_mutex_lock() not being released until the signal had been
handled and cygwin not executing the handler until the end of the lock,
the signal is however deferred FOREVER, which brakes this assumption.

One could probably argue that this is not explicitly forbidden by the
POSIX standard, however it's not how Linux or any other semi-posix-like
system works, and it makes certain programming constructs 
(in this case a user space scheduler) basically impossible to implement.


Well long story short, I am trying to get a backtrace of the segfault
caused by the other signaling bug with a current debugging enabled
cygwin.dll and post it here, if you don't already have that.

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