X-Recipient: archive-cygwin@delorie.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.4e871a91@CorvusMC.home> <20100713090755.31f0664f@CorvusMC.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@cygwin.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.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