https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93456
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu.org
--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
On arm-vxworks, that has 32-bit time_t, this also fails. The initial
gthread_cond_timedwait sleeps for a second or two, then it times out and
returns. However, the wider C++ types used in the
condition_variable::__wait_until_impl check for a timeout and decide we have
NOT timed out, so the __Predicate version of __wait_until sees the condition
it's waiting for hasn't been met, and attempts to wait again. But since the
timeout has already been reached, gthread_cond_wait returns immediately, and we
busy-loop. Since vxworks won't preempt threads, and we're not in a SMP
configuration, the async call never gets a chance to complete, and the test
runs till the rlimit runs out.
While investigating this, I noticed that adding __gthread_yield calls in the
__wait_until_impl loop, the other thread gets enough cycles to complete, and
the test passes, but I thought that would defeat the point of the test, right?
