http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #18 from Danny Waser waser@waser.tech --- Update: Encountering NTsync’s “nasty beast” and DLL modification insights
Funny story: while experimenting with NTsync, I managed to stumble into one of those infamous Wine concurrency edge cases:
``` 0398:err:sync:RtlpWaitForCriticalSection section 00000000DE985360 "?" wait timed out in thread 0398, blocked by 0418, retrying (60 sec) ```
I suspected something interesting might happen, but I definitely underestimated how disruptive it would be — shutting down my system became so tricky I had to resort to drastic measures.
Another amusing discovery: Proton actually patches the affected DLLs to sidestep this issue entirely. That explains why so many users seemed confused about these deadlocks — they simply never encountered them, thanks to Proton’s workaround.
Personally, I prefer to keep the DLLs as close to their original state as possible. In this case, it makes much more sense to have the compatibility layer (Wine) expose the hardware topology directly to native Windows APIs. After all, the Linux kernel already provides this information; we just need Wine to reformat and present it correctly for Windows compatibility.
Sometimes, the best solution is not to patch around the symptom, but to let the system’s real capabilities shine through.