This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc 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]

[Bug nptl/21291] pthread cancellation fails when contending lock


https://sourceware.org/bugzilla/show_bug.cgi?id=21291

--- Comment #6 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Dimitri Staessens from comment #5)
> After re-reading the POSIX specification, I think this unspecified behaviour
> you mention is only allowed if the application is already executing the
> cancellation point. 

I don't see wording that would require this.  I think the third sentence in the
relevant POSIX paragraph, which I quoted, is a third case distinct from the
other two.

I also don't see why this would limit what applications can do.  If the
application actually enforces that pthread_cancel has finished execution in
another thread before the respective pthread_cond_timedwait call started, then
the application must be able to check whether that's the case in the condvar
wait loop.  The timeout is there and it works.

One could argue that the special casing for the timeout case is not explicitly
spelled out for other kinds of errors; for example, must the implementation
check for a cancellation request before it returns EINVAL because the supplied
timeout is bogus?  But would that make sense?

You could ask the Austin Group for clarification, if this issue is important to
you (but I'd suggest to include the EINVAL case as well).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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