On 11 October 2012 17:05, Jack Howarth wrote: > > Jonathan, > The committed patch results in the expected this_thread::yield() and > this_thread::sleep_for() > support. I did run into a regression at -m32/-m64 on darwin10 (but not > darwin11/12). > > WARNING: program timed out. > FAIL: 30_threads/condition_variable/54185.cc execution test
That's PR 54407, so not a regression. > This actually isn't that surprising because the pthread support is buggy on > darwin10. We always randomly > fail the execution test for 20_util/shared_ptr/thread/default_weaktoshared.cc > on darwin10. I filed that > as radr://7905357, "testcase > 20_util/shared_ptr/thread/default_weaktoshared.cc thread handling bug" back > in 2010 and it was fixed in darwin11. Either we tolerate this regression on > darwin10 or we can > add something like... > > Index: libstdc++-v3/config/os/bsd/darwin/os_defines.h > =================================================================== > --- libstdc++-v3/config/os/bsd/darwin/os_defines.h (revision 192370) > +++ libstdc++-v3/config/os/bsd/darwin/os_defines.h (working copy) > @@ -43,8 +43,10 @@ > #define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC > > // Configure checks for nanosleep fail on Darwin, but nanosleep and > -// sched_yield are always available, so use them. > +// sched_yield are always available, so use them 10.6 or later. > +#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1060 > #define _GLIBCXX_USE_NANOSLEEP 1 > #define _GLIBCXX_USE_SCHED_YIELD 1 > +#endif > > #endif > > Hopefully Mike can chime in with an opinion here. I'll test this workaround > later today on darwin10. I don't think that will make any difference, because that test was already failing anyway.
