On Wed, 26 Jul 2023 23:29:41 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>>> > > 3. Do another CoInitialize before call :- not a good approach >>> > >>> > Yet it does not break the rules: you can initialise COM, call an API and >>> > then call >>> > [`CoUninitialize`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize). >>> > If you don't keep any references to COM objects, it is valid. >>> >>> Tried this approach and it works, we may need to do the similar approach >>> for another function `DAUDIO_GetDirectAudioDeviceDescription` because this >>> also calling `DirectSoundEnumerateW `& `DirectSoundCaptureEnumerateW ` >> >> Does this approach return full names for devices, without truncating them? > > But if that code requare com my expectation would be that they call > CoInitialize/CoUninitialize. > > This CoInitialize initially was added here > https://bugs.openjdk.org/browse/JDK-6950553 (check the stack trace), > https://github.com/openjdk/jdk/commit/b8b9c35567919f9f375cc3610d823524cf5b8582 > can we check that the DAUDIO_GetDirectAudioDeviceDescription is really uses > that com object w/o initialisation? >>1. Call CoInitializeEx, enumerate devices, and call CoUninitialize. >>2. Create an executor service which initialises COM on its worker thread, >>enumerate devices on the worker thread and return the devices. The worker >>thread may terminate (after it calls CoUninitialize) if it doesn't receive >>more requests in a period of time. > > We can try reuse the "Filechooser.invokeCom" machinery, but I do not think I > like it. is it possible that our "::CoInitialize(NULL);" prevents the ::CoInitializeEx(NULL, COINIT_MULTITHREADED); in the lib later? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1275577287
