X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.5 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: References: Date: Tue, 13 Jul 2010 06:54:24 +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 01:08, James Cotton wrote: > Sorry, I don't have access to the actual POSIX standard It's at http://www.opengroup.org/onlinepubs/9699919799. > but my > interpretation is based on man pages: > > https://computing.llnl.gov/tutorials/pthreads/man/pthread_mutex_lock.txt > > And certainly nowhere have I see "pthread_mutex_lock blocks signals". > The signal we are using is SIGUSR1. =C2=A0I don't see why the signal would > be deferred since there are no signals being blocked. =C2=A0Possibly the > first signal gets caught and another one comes while in the signal > handler (where usual that signal should then get blocked) and is > disrupting the processing. Makes sense. 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