On Tue, 28 Aug 2012, Andrew Whitworth wrote: > Yes, that patch actually does look very reasonable. Does it change the > test results you've seen, at all?
It's too early to say -- it'll probably take until tomorrow afternoon for me to have chance to run the full test suite on any "interesting" machines. A quick check on OpenBSD shows that it no longer hangs in the t/pmc/timer.t test, so I think it's on the right track. > On Tue, Aug 28, 2012 at 10:34 AM, Andy Dougherty <[email protected]> > wrote: > > I've never really done any threads programming, so I could be quite off > > here, but it looks to me as if there's a race condition in src/alarm.c in > > the threads branch. Specifically, Parrot_alarm_init() creates a thread > > that checks sleep_cond before it initializes sleep_cond. (Similar remarks > > hold for alarm_lock.) > > > > Does this patch look appropriate? > > > > diff --git a/src/alarm.c b/src/alarm.c > > index 298387f..0ec6a1f 100644 > > --- a/src/alarm.c > > +++ b/src/alarm.c > > @@ -56,9 +56,9 @@ Parrot_alarm_init(void) > > { > > ASSERT_ARGS(Parrot_alarm_init) > > Parrot_thread thread; > > - THREAD_CREATE_JOINABLE(thread, Parrot_alarm_runloop, NULL); > > MUTEX_INIT(alarm_lock); > > COND_INIT(sleep_cond); > > + THREAD_CREATE_JOINABLE(thread, Parrot_alarm_runloop, NULL); > > } > > > > /* > > > > -- > > Andy Dougherty [email protected] > > _______________________________________________ > > http://lists.parrot.org/mailman/listinfo/parrot-dev > -- Andy Dougherty [email protected] _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
