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.
This case can be considered as a programmers error (we should guard against it if possible, though). When the "main" or first interpreter terminates the packfile with the opcodes is destroyed. A still running thread wouldn't have any more code to execute.
... 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.
B) if any, but it's not only freeing the interpreter array. The last one has to do all the work that the main interpreter should have done.
See also src/inter_create.c:Parrot_really_destroy()
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?
There are presumably some more leaks in the code, yes - err no ;-)
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.
I don't think so: in line 47 the thread enters the runloop, state is JOINABLE (except when created detached). Another thread, which has the TID of the thread can now join or detach it. Only when the thread leaves its runloop, it's state is set to FINISHED. So at e.g. line 322 it can be JOINABLE (still running) or FINISHED. The JOIN() then gets the return result, which possibly causes the caller to wait for the thread to finish.
Argh, yes. Can you just #undef the CONST after including the windows.h?
Ok, done it.
Good.
Thanks, applied leo
