[pm-lucarohde]

PR Details

Dispatcher.ForBatched busy-waits on ThreadPool.Instance.TryCooperate() until all batches
are done. While the work queue is empty, this loop never makes a system call. Under
Wine/Proton with .NET 9+, CoreCLR suspends threads for GC with special user-mode APCs
(QueueUserAPC2), and Wine doesn't deliver those to such a thread. So a GC that starts during
this wait deadlocks the process. In Game Studio, this freezes the editor ~30–45 s after
opening a project.

When running under Wine, the loop now also calls a trivial regular P/Invoke
(kernel32!GetCurrentThreadId) each iteration. The call goes through preemptive mode, so a
pending GC can proceed and the thread waits for it on return. It never yields the time slice.
Wine is detected once (ntdll!wine_get_version) into a static readonly bool, so tiered JIT
removes the check on other platforms. The busy-wait itself is unchanged.

Testing: with the real Stride.Core under GE-Proton11-6 / unpatched .NET 10.0.13, master
hangs 3/3 and this branch passes 3/3. Natively on Linux it passes too (details in the
comments).

Related Issue

Fixes #3599
Related: #3419

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the editor to try this change out.

[pm-lucarohde]

@dotnet-policy-service agree

[Eideren]

The thread running this method is often (not always) the main thread. We definitely can spinwait, but we can't yield the timeslice here; games run on busywait or vblank loops, having a single thread hammered 24/7 helps reduce discrepancies in frame to frame interval.

Now this is definitely an issue that's not just localized around your specific setup as the gamestudio's threads in general do not necessarily follow this ethos. It spawns a ton of games and they all compete for the same resources with little to no orchestration.
I would like to improve that point, but there are more pressing tasks right now.

This change definitely introduces performance regressions, not as a constant cost, but one of stability under load, I would rather not accept it as is. Couple areas worth investigating instead:

• A non-yielding native method the GC can interrupt in your setup, seems unlikely but might as well validate that
• Listen for GC suspensions and let it yield then, same as above
• Detect this specific setup and add a specific path for it, preferably something that can be JITed away when running outside of that path.

[pm-lucarohde]

@Eideren

Thanks, makes sense. I pushed d5bec23, which combines 1 and 3: the original busy-wait is back and never yields.

1. Native call: works. A regular P/Invoke (GetCurrentThreadId, no [SuppressGCTransition]) goes through preemptive mode, so the GC can proceed without the APC, and the thread waits for it on return. No syscall, no yield, and the cost is within noise (~5 ns/iteration with and without it, under Wine). Thread.SpinWait would work too, but it adds a ~33 ns pause on every platform.

2. Listening for GC suspensions: not possible, as far as I can tell. Nothing in managed code exposes a pending suspension. The P/Invoke return in 1 is exactly that check, just done by the runtime.

3. Wine-only path: works. Wine is detected via ntdll!wine_get_version into a static readonly bool. Outside Wine, the Tier1 code has no trace of it (checked with DOTNET_JitDisasm).

Test with the real Stride.Core (GE-Proton11-6, unpatched .NET 10.0.13): Dispatcher.For in a loop while another thread forces GCs. master hangs 3/3, d5bec23 passes 3/3. Natively on Linux it passes too.

[Eideren]

Looks good, thanks!

[Kryptos-FR]

Shouldn't it test if TryCooperate() returned false before doing the Poll()?

[pm-lucarohde]

Shouldn't it test if TryCooperate() returned false before doing the Poll()?

Good point! I’ve revised it.

[Kryptos-FR]

The Wine hang seems fixed in Wine 11. Nevertheless, I think this small fix doesn't hurt and can prevent any other future regression.

[MsEpsilon]

I'm having freezes when the GameEditor is building thumbnails (stuck at 247 in queue, with a empty project with all assets packs installed) despite running Wine 11.0.

[xen2]

@MsEpsilon your freeze still happen with this branch?
If yes, one candidate: RootRenderFeature.GetOrCreateObjectNode (around line 155) has an empty while (Volatile.Read(...) == -2) { } spin. The thread it waits on calls objectNodes.Add, which can allocate and trigger a GC, so it could hit the same problem. Fine as a follow-up.