Windows NT synchronization primitives for Linux

Posted Feb 23, 2024 17:47 UTC (Fri) by mb (subscriber, #50428)
In reply to: Windows NT synchronization primitives for Linux by timon
Parent article: Windows NT synchronization primitives for Linux

Please see the root of this thread.
This is going way off topic to what I originally commented on.

The original assumption was that there were *zero* use cases. (which was *not* claimed by me)
Which has been clarified as being wrong.

The corrected assumption is that there are proprietary apps hidden somewhere that wine does not want to break.
Whether that warrants a kernel driver or not is a completely different question. IMO it doesn't, but feel free to have a different opinion. I'm Ok with that.

Windows NT synchronization primitives for Linux

Posted Feb 23, 2024 18:35 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

Note that the thing that warrants a kernel driver is the wait-for-any functionality of the call; the challenge is that if the kernel driver only implements wait-for-any, and neither implements a way to "return" those waits to userspace early nor a wait-for-all option, then Wine has a regression and won't use this driver for wait-for-any, even though it works for that purpose.

The exact implementation of this is up to the people doing the work; do you put a wait-for-all mode in the kernel, even though it's rarely needed, or do you come up with a way for Wine to reclaim all the wait-for-anys sitting in the kernel and push all wait-for-anys (including the reclaimed ones) through the slow path, not using the kernel driver?

Both work, since we only have evidence that there are applications that do not use wait-for-all, but would benefit from a faster wait-for-any than can be implemented in userspace alone.

Windows NT synchronization primitives for Linux

Posted Feb 29, 2024 18:55 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

> the challenge is that if the kernel driver only implements wait-for-any, and neither implements a way to "return" those waits to userspace early nor a wait-for-all option, then Wine has a regression and won't use this driver for wait-for-any, even though it works for that purpose

I'm catching up but isn't the way that MS solves these kinds of compat issues in the Windows world is tedius baked-in lists of specific applications which need the differential behavior? A WINE config/cli flag that indicates when emulated wait-for-all is needed which uses the existing slow implementation with a default which uses the fast kernel implementation, that aborts with a sensible error if the app uses features which aren't implemented, so the user/admin can restart the app with the right compat option saved. Maybe an option to upload those compat lists somewhere so the config could be distributed, if the existence of the app isn't sensitive data.

I know having things work correctly automatically is more awesome but sometimes just doing the dumb brute force thing is more effective and efficient than working through all the details, coordination and judgement to automate something. Technical debt isn't always bad as long as you are picky when you create it.

Windows NT synchronization primitives for Linux

Posted Feb 29, 2024 19:20 UTC (Thu) by farnz (subscriber, #17727) [Link]

That would work, too, but then needs the people proposing a Linux-only accelerator for wait-for-any behaviour to create the compat options + list, so that people can use it.

This is not an unsoveable problem; it's "just" that Wine isn't happy with a gain in performance for some applications at the expense of others now failing to work at all, and people will have to do the work so that this becomes a gain in performance for some applications (those that only use wait-for-any) but not others.