Re: [Patch] Win32 thread primitives
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
Re: [Patch] Win32 thread primitives
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
Re: [Patch] Win32 thread primitives
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's state is set to PREVIOUS_STATE+FINISHED
So it's never equal to just FINISHED
src/threads.c: 53: interpreter-thread_data-state |=
THREAD_STATE_FINISHED;
src/threads.c: 322: interpreter-thread_data-state ==
THREAD_STATE_FINISHED) {
Typo or what?
Re: [Patch] Win32 thread primitives
Vladimir Lipsky wrote: It's state is set to PREVIOUS_STATE+FINISHED So it's never equal to just FINISHED Ah, Yep. Works for JOINABLE, which is 0, but ... Typo or what? Inexact ;-) leo
[Patch] Win32 thread primitives
This patch defines Win32 thread primitives. Actually it consists of the following files: threads.h.diff thr_windows.h.diff threads.t.diff timer.t.diff The patch had been applied, I mananged to pass all the tests from t/pmc/thread.reast and t/pmc/timer.t but thread_4.pasm(don't know yet why it fails) The other files are needed the patch to compile and work properly: events.c.diff - contains fix for correct deteremination of the tv_nsec value. Now it is always equal to zero. imcc.l.diff, imcc.y.diff et al - contain a dirty hack which prefixes the CONST lexeme with underscore, otherwise CONST conflicts with MACRO from windows header files. Probably the solution wwould be to prefix all the lexemes with IMCC_ or whatever. Prefixing should be done for thread primitives either. events.c.diff Description: Binary data imcc.l.diff Description: Binary data imcc.y.diff Description: Binary data imclexer.c.diff Description: Binary data imcparser.c.diff Description: Binary data imcparser.h.diff Description: Binary data main.c.diff Description: Binary data thr_windows.h.diff Description: Binary data threads.h.diff Description: Binary data threads.t.diff Description: Binary data timer.t.diff Description: Binary data
Re: [Patch] Win32 thread primitives
Vladimir Lipsky wrote: This patch defines Win32 thread primitives. Great. ...Actually it consists of the following files: threads.h.diff thr_windows.h.diff threads.t.diff timer.t.diff Small nitpick - please provide just one patch file - applying is much simpler then, or less work ;) The patch had been applied, I mananged to pass all the tests from t/pmc/thread.reast and t/pmc/timer.t but thread_4.pasm(don't know yet why it fails) 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() imcc.l.diff, imcc.y.diff et al - contain a dirty hack which prefixes the CONST lexeme with underscore, otherwise CONST conflicts with MACRO from windows header files. Probably the solution wwould be to prefix all the lexemes with IMCC_ or whatever. Prefixing should be done for thread primitives either. Argh, yes. Can you just #undef the CONST after including the windows.h? leo
