https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> --- Yes, I've raised this with the AIX pthreads team, but they disagreed with my interpretation of POSIX. They said my reduced example was incorrect because pthread_cond_destroy() and pthread_mutex_destroy() can return EBUSY, and so libstdc++ is buggy for not handling that case. Quoting from my replies to them ... -- >8 -- I disagree with that interpretation. EBUSY is allowed if threads are still waiting, but my test wakes them up before doing pthread_cond_destroy. See the (admittedly informative) EXAMPLES section at https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_destroy.html which says: "A condition variable can be destroyed immediately after all the threads that are blocked on it are awakened." The example doesn't bother to check the return code, because it is correct by construction (the destroy follows a broadcast) and so can't fail. In any case, that error code isn't allowed in the latest version of POSIX. The changes for Issue 7 say: "The [EBUSY] error for a condition variable already in use or an already initialized condition variable is removed; this condition results in undefined behavior." This confirms that EBUSY is not an acceptable result for correct uses of pthread_cond_destroy (i.e. ones where there are no waiters, as in my example). -- >8 -- I'm not sure if I convinced them.
