X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.7 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <20100713090755.31f0664f@CorvusMC.home>
References: <AANLkTimmJ1HNGW1fJMhvHg9a3Pgk1PDbR2rubnexczIv AT mail DOT gmail DOT com>	<20100712230519 DOT 4e871a91 AT CorvusMC DOT home>	<AANLkTik6e4W5bE2BcsKDIrjtFY4qXwVOWq8uFFgytJKW AT mail DOT gmail DOT com>	<20100713090755 DOT 31f0664f AT CorvusMC DOT home>
Date: Tue, 13 Jul 2010 12:16:03 +0100
Message-ID: <AANLkTimGXX8Jm3gkbrx25p6mWQj2EitAKqFSs_L8loFz@mail.gmail.com>
Subject: Re: pthread_mutex_lock doesn't interrupt
From: Andy Koppe <andy DOT koppe AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
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

On 13 July 2010 08:07, Corvus Corax wrote:
>> Have you got chapter and verse from the POSIX standard on that? By
>> 'interrupt' do you mean SIGINT or any signal? Is it possible that the
>> signal is just being deferred and then subsumed by later signals?
>>
>> Andy
>
> PTHREAD_MUTEX_LOCK() has been defined in IEEE POSIX 1003.1c.
>
> From the POSIX Programmers Manual:
>
> http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lo=
ck.html
>
>> If =C2=A0a =C2=A0signal is delivered to a thread waiting for a mutex, up=
on
>> return from the signal handler the thread shall resume waiting
>> for =C2=A0the =C2=A0mutex as if it was not interrupted.
>
> As you can see from the test cases (attached to the other mail)
> only one type of signal (SIGUSR1) is repeatedly sent, but not handled.
>
> I am not sure if I understood what you mean by "deferred".

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.

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