[kaffe] frustrating news regarding the pthread instability

[Dalibor Topic]

Noa Resare wrote:
> ons 2004-10-20 klockan 18:47 +0200 skrev Guilhem Lavaux:

> I have now tested the new code a bit. I have succeeded to hang it once
> after about 5 hours of testing (but that could be related to the problem
> below) but it is much more stable than any other kaffe version I have
> tested.

That's some good news! thanks!

> I have however found out empirically that KGC_rmRef() in tDispose()
> somehow uses the thread local kSem, so KaffeVM_unlinkNativeAndJavaThread
> (which calls ksemDestroy) needs to be invoked after that, not before.
> Applying the attached patch fixes fairly frequent lockups with Fedora
> Core 2.92 (it takes about a minute to reproduce the lockup).

Thanks, I've committed the patch.

> Random thoughts: 
> 
> - in unlinkNativeAndJavaThread(), the only unlinking that takes place
> seems to be that the jniEnv member is set to 0. Since this is the last
> time (?) the thread_data structure is ever accessed the value of jniEnv
> shouldn't matter to anyone. Therefore the name unlinkNativeAndJavaThread
> is not only ugly but also misleading :P

Yeah. Feel free to refactor the name to something else.

> - since the thread local ksem seems to be used by a variety of seemingly
> unrelated code (locking, the gc interface) It is important that it is
> initialized as early as possible and destroyed as late as possible in a
> thread's life cycle. It is also important that this is only called for
> new and not for reused threads (not that we have any atm).

We could add a 'status' field to ksem in debugging mode to represent its 
known status: initialised/destroyed and add asserts for ksem operations 
to check if the status is ok (again when debugging is enabled).

cheers,
dalibor topic