Am 13.06.10 20:35 schrieb Levente Uzonyi:

> If I select JVMWithoutCallbacks(JVM)>>own: in the debugger and inspect the
> instance variable "sharedMutex", I find that the UI process is still the
> owner of the mutex, the mutex's semaphore has no signals and the process
> is in the list of the semaphore. But the process is not in the critical
> section of the mutex, because the block containing the #critical: send is
> already evaluated (JNIPortWeakRegistry>>registerValueOf:). So the mutex is
> "locked", but it's not used by the process that "locks" it.
> The deadlock occurs, because the finalization process is trying to access
> the same mutex to finalize the objects, while it's also in the critical
> section of the WeakRegistry's semaphore. While this is happening, the UI
> process is trying to register new objects to the WeakRegistry.
> I couldn't find out how can the Mutex have this invalid state.

I am going to look into this, but this week I am quite busy, so it may take
some time.

However, I think that it's unsafe to send #finalize to the executors while
WeakRegistry is still in the protected block in finalizeValues. You don't
have control over what finalize is doing, and this can lead to deadlocks if
a #finalize waits on a Semaphore. Would it be possible to collect the
objects to be finalized in a collection in the protected block, and finalize
them afterwards?

Joachim