Bug#459322: closed by Pierre Habouzit <madcoder@debian.org> (Re: Bug#459322: libc6-dev: implementation of pthread_cleanup_pop_restore_np)
"Also sprach Debian Bug Tracking System:"
> It has been closed by Pierre Habouzit <madcoder@debian.org>.
>
> Their explanation is attached below. If this explanation is
> unsatisfactory and you have not received a better one in a separate
The "explanation" is nothing of the kind, and is unsatisfactory. I have
quoted the manpage, provided a simple testcase, and the testcase shows
the behaviour to contraduict the manpage.
Resolve that contradiction. Change the manpage if you must!
And please stop this extremely rude practice of "closing" a bug report
before you have even talked to the sender, let alone agreed a negotiated
and mutually satisfactory conclusion toit. It is impolite, disrespectful,
abusive, and the worst sort of annoying administrative burocratic
behaviour, precisely because of that.
> It's not according to its author:
> http://sourceware.org/bugzilla/show_bug.cgi?id=5626
Whatever that says, it would be in contradiction to the manpage, since
the test program shows the code to be in contradiction of its manpage. So
fix one or the other!
He seems to say:
The code is wrong. There calling of the cleanup function and the
resetting of the cancellation state is not atomic. This means,
pthread_mutex_unlock is called with cancellation set to async. This
must never happen.
In the first place, calling the cleanup function is done by YOU. He is
saying YOUR code is wrong, as far as I can tell. I don't call it at all.
Second, if he means the cleanup function is "not atomic", I don't know
what he means since it has three lines.
1) call mutex_unlock
2) test error code
3) print error message if error nonzero
Remove lines 2 and 3 if you prefer. It doesn't change anything.
Third, he is saying what I AM SAYING. The code (for the library/macro
calls) is wrong. He is repeating exactly what I have saud. HE AGEEESA
WITH ME. He states exactly what I said .. " pthread_mutex_unlock is
called with cancellation set to async". Indeed, that is BECAUSE YOU PUT
THE THREAD BACK INTO ASYNC STATE BEFORE THE unlock runs. You did it. Not
me. That is what is wrong!
> message then please contact Pierre Habouzit <madcoder@debian.org> by replying
> to this email.
Fair enough. But it seems that Pierre isn't that hot on logical
reasoning.
Peter
Reply to: