[Win32] Initialize Windows Runtime on queue threads

[triplef]

On Windows, all threads that want to use Windows Runtime or COM components must be initialized with a call to CoInitializeEx() or the slightly more modern RoInitialize() (same as Windows::Foundation::Initialize).

This change initializes all libdispatch threads so it’s possible to use COM and Windows Runtime APIs.

[stevenbrix]

is it possible to have app authors determine which initialization method to use? would this make the @MainActor thread an MTA thread? that should likely be STA (which is what conventional Windows GUI apps use today)

[compnerd]

is it possible to have app authors determine which initialization method to use? would this make the @MainActor thread an MTA thread? that should likely be STA (which is what conventional Windows GUI apps use today)

No, I don't see how to do that. These threads are spawned without user intervention, and I don't remember any APIs to control the worker threads it creates. Is there a global Windows API that lets you set the apartment model?

[stevenbrix]

@compnerd given the behavior of .NET it seems correct to initialize background threads to MTA: https://learn.microsoft.com/en-us/dotnet/api/system.threading.thread.setapartmentstate?view=net-7.0#remarks

if needed perhaps we could evolve this in the future but not an immediate need

[compnerd]

@compnerd given the behavior of .NET it seems correct to initialize background threads to MTA: https://learn.microsoft.com/en-us/dotnet/api/system.threading.thread.setapartmentstate?view=net-7.0#remarks

if needed perhaps we could evolve this in the future but not an immediate need

Well, this is only for background threads, so this sounds like we have a path forward. I think that the only thing missing here is the death for an error scenario.

@triplef any chance you can update the patch?

[stevenbrix]

looking at the implementation of .NET, it looks like they call both: https://github.com/dotnet/runtime/blob/991b15056e276209b64a711face35715ba335c77/src/coreclr/vm/threads.cpp#L4898

https://github.com/dotnet/runtime/blob/991b15056e276209b64a711face35715ba335c77/src/coreclr/vm/threads.cpp#L5054-L5057

also looks like ignoring an unexpected HRESULT might be acceptable?

[compnerd]

looks like ignoring an unexpected HRESULT might be acceptable?

It may be that its easier to debug the .NET runtime, things are a bit more complicated with debugging dispatch, I'd rather be more stringent. The number of times that the dispatch assertions have saved me hours of debugging is ridiculous. Blindly following .NET doesn't seem like the right thing to me.

[triplef]

I’ve updated the patch with a fatal error message in case COM initialization fails. Let me know if there’s any other changes needed.

[compnerd]

@swift-ci please test

[compnerd]

@swift-ci please test Windows platform

[compnerd]

@swift-ci please test Windows platform

[tristanlabelle]

Can we safely assume that CoInitializeEx is enough to initialize the Windows Runtime, when Roinitialize doesn't mention this?

[triplef]

There was an earlier discussion about these functions here, does that maybe answer your question? Unfortunately I’m not familiar with the differences between the two functions.

[rilysh]

CoInitializeEx initialize concurrent model as STA, where RoInitialize by default uses MTA. Though passing RO_INIT_SINGLETHREADED will use STA instead.