Andy Armstrong wrote:
Again, let me know if you need more.
I pushed it far enough that I was able to repeat the deadlock hang on OS
10.4.11, that's good. The interesting thing was the order of operations.
The usual order is:
call to Parrot_cx_init_scheduler
initializing scheduler runloop
started scheduler runloop
sleeping in scheduler runloop
call to Parrot_cx_runloop_end
terminating scheduler runloop
handling tasks in scheduler runloop
Found task ID # 1
ended scheduler runloop
with initialization, followed by running, followed by termination. The
hang happened with:
call to Parrot_cx_init_scheduler
initializing scheduler runloop
call to Parrot_cx_runloop_end
started scheduler runloop
terminating scheduler runloop
sleeping in scheduler runloop
where the call to terminate the runloop happens before the runloop even
gets fully started. That gives me an area of code to focus on, in
reviewing for sources of deadlocks.
(This whole headache is because the scheduler is currently using
mutex/lock variable sharing instead of STM. Which is nice confirmation
to me that we should be moving the core sharing strategy to STM, after
we more fully develop Parrot's STM implementation.)
Allison
