Vladimir Lipsky wrote:
>> 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
|
