Re: Fixes for generic pthread_cond_*wait functions
Ulrich Drepper <[email protected]>
| Newsgroups | gmane.comp.lib.phil |
|---|---|
| Organization | Red Hat, Inc. |
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Terekhov wrote: > IMO the right "fix" for the second one is nothing but abort(). THere is nothing like this in the standard. In fact, no correct program can fail this way since you would have to do something to the mutex in a signal handler which isn't allowed. Still, reporting the problem is fine. If you don't like it, file an interpretation request. > - a rather mysterious "cbuffer.oldtype" beast; > > - lack of some measure(s) to ensure that a canceled thread does > NOT consume a "concurrent" signal -- "A thread that has been > unblocked because it has been canceled while blocked in a call > to pthread_cond_timedwait() or pthread_cond_wait() shall not > consume any condition signal that may be directed concurrently > at the condition variable if there are other threads blocked > on the condition variable." > > Or am I just missing and/or misunderstanding something? What is your problem? If the signal handler is called no condvar signal is used. - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+bjTE2ijCOnn/RHQRAu4nAKC1i1Uca/HVdQL9yghAwHF1XRF5cgCgna7Z lWxUVK/pDfJiX6KVCZI7aoo= =z0Jw -----END PGP SIGNATURE-----