Re: Improving --enable-libstdcxx-time

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

Coming back to this old thread ...

On 28 May 2012 19:11, Jonathan Wakely wrote:
> We need to do something about the fact that this_thread::yield() and
> this_thread::sleep_for() are only defined when GCC is built with
> --enable-libstdcxx-time, which most users and distros don't do.

For 4.8 I made this_thread::yield() a no-op when we're not using
sched_yield, and uses ::usleep() when we're not using nanosleep().
This makes the <thread> header complete even when
--enable-libstdcxx-time is not used.

> I think defaulting to --enable-libstdcxx-time=yes would give an more
> complete <chrono> and <thread> implementation on most platforms.  Are
> there any reason not to do that?

To answer my own question, we don't check for them because it requires
linking, which isn't always possible at configure time.

(It's annoying that most people get a less-capable libstdc++ because
some people can't do link tests at build time, but c'est la vie.)

> To get maximum clock resolution on GNU/Linux it's still necessary to
> use --enable-libstdcxx-time=rt, causing a performance hit in
> single-threaded code that uses libstdc++.  That could be solved by
> splitting libstdc++.so into two, the existing lib and a new one
> providing system_clock::now() (and maybe the C++11 thread classes.)
> Progams that don't use system_clock and don't use threads would only
> link to libstdc++.so, programs that do use them would link to some
> extra lib, say libstdc++11.so, which links to libpthread.so and also
> links to librt.so if configured with --enable-libstdcxx-time=rt.

Paolo suggested asking for help from glibc, and Roland McGrath moved
clock_gettime out of librt for glibc 2.17, which is great (thanks,
Roland!)

That will allow something like the attached patch for GCC 4.9, which
makes --enable-libstdcxx-time=yes the default, without needing link
tests, for platforms known to support the needed functions. This
enables an almost complete C++11 thread library and high-resolution
std::system_clock with the default configuration on GNU/Linux. It's a
shame it's too late for GCC 4.8, as it means it probably won't make it
into Fedora 19 and other distros that will have glibc 2.17

> That would solve another minor problem: It was recently pointed out to
> me that requiring -pthread to use std::thread is a leaky abstraction
> because users of std::thread shouldn't need to know it's implemented
> in terms of pthreads. If there was a separate library providing the
> C++11 thread features then users could use -lstdc++11 to enable them,
> and libpthread.so and librt.so would be automatically linked to if
> needed.  We could add a -cxxthread switch which would expand to
> -lstdc++11 and would be relevant to all thread models and platforms so
> would be portable (which -pthread isn't), documented (which -pthread
> isn't), and not require users to know that they need to use -pthread
> to enable std::thread.

This isn't needed to solve the library dependencies now, but I still
think there should be a better-named option than -pthread for using
std::thread.