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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.