threads_4 is testing killing threads. This is achieved by scheduling a terminate event to the running interpreter. This can only succeed, if the event system is running too.
see src/events.c/Parrot_new_terinate_event()
Though thr_windows.h doesn't contain error checking for now, it luckily fails when the killed thread returns from runops and tries to LOCK the interpreter_array_mutex. But before that the thread of the main interp had time to call Parrot_really_destroy, loop interpreter_array, and free interpreter_array_mutex. Here I see two solutions:
A) do not free the array and mutex asscociated with it at all; those are global, malloced once, have no destructor, would it be a memory leak?
B) the very last thread do the work, it iterates thru array and if all tids are null(except itself), free array and mutex.
On the another hand I didnt see that interpreters task queues and mutexes of the shared pmc's(sub and Interp, probably) were freed up anywhere. It's that normal?
And on the third hand, if I understood the code correctly ...
src/threads.c: 40: thread_func() src/threads.c: 53: interpreter->thread_data->state |= THREAD_STATE_FINISHED;
src/threads.c: 312: pt_thread_join ()
src/threads.c: 321: if (interpreter->thread_data->state == THREAD_STATE_JOINABLE ||
src/threads.c: 322: interpreter->thread_data->state == THREAD_STATE_FINISHED) {
src/threads.c: 453: detach()
src/threads.c: 462: if (interpreter->thread_data->state == THREAD_STATE_JOINABLE ||
src/threads.c: 463: interpreter->thread_data->state == THREAD_STATE_FINISHED) {
lines 322, 463 never hold true, because of line 53. So pt_thread_join, detach are never able do their work on threads that have runops-ed.
Argh, yes. Can you just #undef the CONST after including the windows.h?Ok, done it.
win32_threads.patch
Description: Binary data
