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: <20100712230519 DOT 4e871a91 AT CorvusMC DOT home> <20100713090755 DOT 31f0664f AT CorvusMC DOT home> Date: Tue, 13 Jul 2010 12:16:03 +0100 Message-ID: Subject: Re: pthread_mutex_lock doesn't interrupt From: Andy Koppe 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: 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 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