[Bug libstdc++/887] libstdc++-v3 modulator setw does not work writing to a file

aaron at aarongraham dot com gcc-bugzilla@gcc.gnu.org
Tue Jul 7 17:00:00 GMT 2015


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=887

--- Comment #9 from Aaron Graham <aaron at aarongraham dot com> ---
Thanks. I had already patched our gcc so that gthreads cond always gets
initialized with CLOCK_MONOTONIC, then I switched __clock_t in
condition_variable to steady_clock. It was a very simple change and works
well but not nearly as portable as yours.

I also disabled all timed waits on mutex (gcc already has ifdef for that)
in order to avoid problems there. In my opinion, people shouldn't be using
timed waits on mutexes anyway, since they are not cooperatively
interruptible. If we did need them for some reason, I would reimplement
timed mutex in terms of condition_variable and a regular mutex.

It seems strange that this is no big deal to lots of people.
On Jul 7, 2015 11:51 AM, "mac at mcrowe dot com" <gcc-bugzilla@gcc.gnu.org>
wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
>
> --- Comment #10 from Mike Crowe <mac at mcrowe dot com> ---
> (In reply to Mike Crowe from comment #9)
> > 3. condition_variable should support wait_until using at least
> steady_clock
> > (CLOCK_MONOTONIC) and system_clock (CLOCK_REALTIME.) Relative wait
> > operations should use steady_clock. User-defined clocks should probably
> > convert to steady_clock.
> >
> > I believe that only option 3 makes any sense but this requires an
> equivalent
> > to pthread_cond_timedwait that supports specifying the clock. The glibc
> > implementation of such a function would be straightforward.
>
> I've proposed a patch that implements this option at:
>
>  https://gcc.gnu.org/ml/libstdc++/2015-07/msg00024.html
>
> and the required glibc change at:
>
>  https://sourceware.org/ml/libc-alpha/2015-07/msg00193.html
>
> --
> You are receiving this mail because:
> You reported the bug.
>



More information about the Gcc-bugs mailing list