Hi,
Do I understand correctly that you think that the blocked finalizer
thread leads to an out of memory condition? Then in my understanding
there is no hope because whatever solution we choose the garbage
collection never will happen while any other API call is processed
inside the OOo process.
Not in the general case, but only if the involved API call can stall the
involved dtor as in Martin's case. Which is bad design, btw...
An approach that might help is if release-calls across the JNI--UNO
bridge (and across other bridges like URP bridges) were done
asynchronously, so that the JVM finalizer thread would not be blocked.
btw, the pyuno bridge does all releases on python objects asynchronously
(for a different reason, the python interpreter requires a global lock
to be held when calling python code [which includes the destruction of
python code). As the global interpreter lock cannot be acquired twice in
the same thread and there is no function to get to know, whether the
lock is held or not, I had to delegate releases to another thread, which
definitely does not have the lock, so I can safely acquire it.
So currently, for every release on a bridged python object, a fresh
thread is created, which in general only decreases a refcount :-(.
Surprisingly, this seems to perform quite ok ...
The java uno bridge need to create also a fresh thread for each release
(or at least for each concurrent release). It can't be a single thread
doing the releases, because this would end in the same problem.
Bye,
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
