Yet another question. Do you know what might call CoInitialize in a
different mode? It looks like we use STA everywhere in JDK.
--Semyon
On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
I meant the case when MTA COM service is actually used, it might cause
issues since the JDK code invokes an another API which assumes
synchronization. At least performance may be affected.
We don't do separate testing of JDK in MTA mode especially on the
regular base. That is why I wouldn't consider MTA mode as supported.
So, before push the change I would make sure of the regression test
suite run in MTA mode hasn't brought any surprises.
--Semyon
On 02/08/2018 11:18 AM, Matthias Bläsing wrote:
Resend: I accidentally dropped swing-dev from receivers (@Semyon I'm
subscribed to swing-dev, so we could direct the mails to the
mailinglist)
Hey Semyon,
Am Donnerstag, den 08.02.2018, 10:52 -0800 schrieb Semyon Sadetsky:
Since you are suggesting to switch from STA to MTA which
consequences
will it have to the current JDK code that was written to support STA
only?
I think there are two questions hidden here:
=== How does this affect the common codepath taken today? ===
It does not. It only changes the behaviour if CoInitalize fails. So
behavioural changes can only occur in environments that did not work
previously.
Before this changeset:
* CoInitialize works => The ShellFolder code can be used as is
* CoInitialize failes => The ShellFolder code raises an exception
After this changeset:
* CoInitialize works => The ShellFolder code can be used as is
* CoInitialize failes => retry CoInitializeEx with multi-threaded
apartment
* if CoInitializeEx fails for multi-threaded apartment raise exception
as before
=== Is it expected to cause problems in the new code path? ====
My understanding of STA vs. MTA is, that it only affects calls from
native to java and not the other way round.
To get calls from outside you'd need to install a callback. My
understanding is, that you'd need to use an IConnectionPoint and call
its Advise method. I did not spot any such methods.
So while I did not go through the whole code base, I think this
changeset should be save.
Greetings
Matthias
On 02/08/2018 10:32 AM, Matthias Bläsing wrote:
referring to this bug:
https://bugs.openjdk.java.net/browse/JDK-8189938
With the instructions given in:
https://bugs.openjdk.java.net/browse/JDK-8193928 (closed as
duplicate of JDK-8189938)
I was able to reproduce the problem on a clean Windows 10
Installation,
as described in the initial report.
The resulting exception leads to my proposed fix:
Could not initialize COM: HRESULT=0x80010106
That HRESULT translates to: RPC_E_CHANGED_MODE
This means, that the COM subsystem is already initialized, but with
a
different mode. The code uses CoInitialize and this initializes the
threading module to be apartment threaded. The above HRESULT means
the
thread was already initialized to be multi-threaded.
The mode can't be changed after is was set once, so instead of
bailing
out, I suggest to accept the situation and initialize to be multi-
threaded.
The consequence is that calls from COM to Java could end up on the
wrong thread. A quick look through the code suggest, that COM
advises
are not used, so this is a risk that should be taken.
The fix in this case works like this:
* try to initialize COM as it was
* check the return
* if it is RPC_E_CHANGED_MODE, retry initialization als multi-
threaded
* only if that fails raise an exception
