This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC 1/2] gthread: Add __gthread_cond_timedwaitonclock


On 06/07/15 15:10 +0100, Mike Crowe wrote:
On Monday 06 July 2015 at 14:51:42 +0100, Jonathan Wakely wrote:
This isn't correct, because it's possible to include <gthr.h> before
including any C++ Standard Library header, so the _GLIBCXX_ macro
defined in libstdc++'s c++config.h will not have been defined.

Presumably gthr-posix.h could just include c++config.h to avoid that, but
perhaps it's not that simple which is why gthr-posix.h swings through hoops
to define _GTHREAD_USE_MUTEX_TIMEDLOCK itself?

In theory you could have a GCC installation without libstdc++ so no
c++config.h. These days we could use __has_include(bits/c++config.h)
to detect that and so could actually solve this problem, but I still
don't think we want this in gthr-posix.h anyway.

It might make sense to just do this internally in libstdc++ and not
involve gthr-posix.h at all, this is what we do for pthread_rwlock_t
usage in <shared_mutex> so you might want to follow that model.

I implemented the new function in gthreads because that seemed to be what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 was suggesting and I'd
incorrectly assumed that there were non-pthreads backends for gthreads too.

There are non-pthreads backends for gthreads, that's the point of
gthreads. But:

1) If you add a new function to gthreads then it becomes part of the
ghtreads API and so in theory it should be implementable by the other
backends. This probably never would be.

2) This isn't even a function that's provided by most pthreads
implementations, so can't even be provided by most users of
gthr-posix.h

3) It is only needed for one place in lisbtdc++ so doesn't need to be
in the generic gthreads API.

I'm can try and re-implement condition_variable using pthreads directly but
the change will be somewhat larger and it would break non-pthreads
platforms.

That's not what I mean. I just mean that we don't need to add a
wrapper in ghtreads and then use that wrapper in <condition_variable>.
You can simply use pthread_cond_timedwaitonclock_np function directly
in <condition_variable> when it is available (as determined by the
_GLIBCXX_ macro, which we do still want).

The comparison to <shared_mutex> was meant to point out that we just
use pthreads directly there, instead of adding rwlock support to
gthreads and then using that. We could do the same for uses of this
function, while stil using gthreads for the rest of
<condition_variable>.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]