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

[Samuel Thibault]

Hello,

Jamey Sharp, le Thu 08 Oct 2009 09:58:06 -0700, a écrit :
> It isn't obvious to me that most of the proposed additions are useful,
> which is why real use cases are important.

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.

> 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.

> Since we don't provide pthread_create, functions operating on
> pthread_attr_t don't seem useful. Why would a library that doesn't
> care about threads ever use them?

Right.

> For either kind of attribute object, it's hard for me to believe that
> returning 0 from the getter functions is a good idea. That's supposed
> to indicate success, but the out-parameters won't have been set, so
> the caller will get garbage. I'd be inclined to not provide any
> getters.

Agreed.

> I have no objection to providing setter functions though. The tricky
> part is that we probably ought to provide *precisely* the collection
> of setters that the platform's libpthread provides. We certainly
> should never provide any that the platform does *not* have.

Right.

> In hindsight, I'm concerned about the fact that we provide
> pthread_cond_wait as a stub returning 0. If it's ever called in a
> single-threaded application, that function should probably call
> abort(). The real implementation would be guaranteed to hang in that
> circumstance, after all. In XCB, we need this to be available as a
> stub, but I can prove that it won't be called unless there are really
> multiple threads.

Agreed.

> 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.

Yes.

> 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.

soci does use 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?

> Providing a pthread_exit that just calls exit seems fine judging by
> the POSIX spec, except that the spec says it should call exit(0),

Oh, I hadn't noticed that and just followed glibc.

> not exit(EXIT_SUCCESS). Just because EXIT_SUCCESS==0 on every sane
> platform doesn't mean we should assume it, right?

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.

> The pthread_getschedparam and pthread_setschedparam functions don't
> seem usable in a single-threaded program to me, but if they are they
> probably shouldn't be implemented as no-ops returning success. I could
> imagine two possibilities: either return ESRCH, because the thread
> argument must be invalid,

It could be pthread_self(), we can check that it's 0.

> or delegate to sched_setscheduler/sched_getscheduler with a pid of 0,
> and return -errno on failure.

Right.

> Since pthread_setcancelstate and pthread_setcanceltype are both
> getters and setters, I'm not sure what a correct stub implementation
> should do. I'd like to see a real use case for this too.

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.

Samuel