This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread_mutex_lock doesn't interrupt

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:
>> 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.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]