Hi Noa,
I am totally for a logical ordering of destruction operation.
Noa Resare wrote:
- pthread_cond_wait() gets called from exitThread() in thread.c (via unlinkNativeAndJavaThread() -> ksemDestroy() -> jcondvar_destroy())
- thereafter jthread_exit() gets called in exitThread() and is
advertised as not returning. This is not true. As can be found in systems/unix-pthreads/thread-impl.c if certain conditions are met it
just returns. when exitThread() returns control is moved to tRun in
thread-impl.c
jthread_exit() should not return. I haven't noticed that. :( I would suggest a special longjmp to reset the stack and go back in the tRun loop directly (though I don't know if it is really legal).
- before tRun() goes on to remove the current thread from the activeThreads list it calls TLOCK() calls pthread_cond_wait() (via lockStaticMutex() -> locks_internal_lockMutex() -> slowLockMutex() -> ksemGet() -> jcondvar_wait())
The obvious way of fixing this IMHO is to delay the unlinkNativeAndJavaThread() invocation until the threads implementation has removed the current thread from the activeThreads list. However this
Hmm... maybe we should change how the thread context is destroyed. unlinkNativeAndJavaThread may be a callback for the threading system so it is called whenever a thread exits and it has already been removed from the active list. It will keep the VM parts in the VM and will give us a way to introduce some sort of specific "finalization".
has an obvious drawback that a required step in thread deconstruction is moved from generic code to threading implementation specific code. (In other words, it needs to be fixed or at leased verified as non- problematic in all threading implementations).
What threading implementations are a priority? Since unix-pthread is
seriously broken at the moment and I suppose that it is by far the most
commonly used threading implementation fixing it is worth some breakage
in lesser used ones.
I can take responsibility for testing a proposed fix on unix-jthread but are there anyone out there taking responsibility for win32, beos-native and oskit-pthreads? Are they used by anyone?
ATM, I am only aware of unix-jthreads and unix-pthreads users. The other threading system are well behind the current design I think (I've already evolved the interface but not all as I don't have access to those systems).
Cheers,
Guilhem Lavaux.
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
