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_lock.html > >> If a signal is delivered to a thread waiting for a mutex, upon >> return from the signal handler the thread shall resume waiting >> for the mutex 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
