[Xcb] Bug#496715: Bug#496715: Bug#496715: libpthread-stubs: Should provide more pthread_* functions

[Jamey Sharp]

On Thu, Oct 8, 2009 at 11:06 AM, Samuel Thibault <sthibault at debian.org> wrote:
> Jamey Sharp, le Thu 08 Oct 2009 09:58:06 -0700, a écrit :
>> Here are some specific concerns, as well as which parts of the
>> proposal I approve of as-is.
>
> I quite generally do agree on them.  I had just reproduced the glibc
> behavior.

Good, that's easy then. :-)

> At least pthread_cond_{init,destroy,wait,timedwait,signal} are used by
> soci without systematically linking against -lpthread.  I mostly added
> the others to anticipate any use rather than waiting for build issues.

I gather "soci" is http://soci.sourceforge.net/ ? Thanks for the
example. It's very helpful.

Are you submitting these patches because you care specifically about
using soci without linking against -lpthread, or did you have some other
motivation?

>> So adding pthread_cond_timedwait now has the same issue, except that
>> I suppose a crazy person could use it to sleep for a specified amount
>> of time. In that case, though, immediately returning 0 would be the
>> wrong implementation. I'd rather not provide any implementation until
>> there's a real library with a sane use case for it.
>
> Either we return ETIMEDOUT immediately, making the user possibly notice
> a 100% cpu usage, or we gently wait for the specified time and return
> ETIMEDOUT?

Right. Except...

I see soci using pthread_cond_timedwait as an alternative to
pthread_cond_wait in the connection pool implementation. (I didn't check
if it appears more places.) It won't call either one until the pool runs
out of connections, and at that point a single-threaded app is broken.

So a third option is to immediately abort() if either pthread_cond_*wait
function is called. What do you think?

> Well, even my oldest copy of xopen (issue 4) specifies that EXIT_SUCCESS
> “evaluates to 0”. I don't know if any standard exists that both
> includes pthreads and doesn't say that EXIT_SUCCESS evaluates to 0. I
> don't believe there is (issue 4 doesn't have pthreads), in which case
> it's either way and I'd prefer EXIT_SUCCESS just for readability.

I won't argue with that. Either patch would seem alright to me, though
it seems pretty strange to use pthread_exit from a library.

> I haven't seen any in the Debian packages yet, but I can very well
> imagine that a library could want to protect itself from unexpected
> cancellation from another thread of the application while doing
> sensitive things.

True, though I think pthread_cleanup_push/pop probably suffices for
those cases? Guess I'd like to see use cases for the scheduler settings
and cancellation bits before deciding what to do.

On Thu, Oct 8, 2009 at 2:26 PM, Samuel Thibault <sthibault at debian.org> wrote:
> Barton C Massey, le Thu 08 Oct 2009 14:03:55 -0700, a écrit :
>> Jamey and I talked about this last week ...
>
> Then please tell the soci maintainers to not use pthread_cond_*

Bart thought this was the bug about the sem_* functions. Don't worry
about it.

Jamey