Tweet
Originally posted by microcode
View Post
Seems to me hard to believe, but I hope you prove me wrong.
-
Do you mean that Windows is ahead of Linux (and it has been such for years) in this respect, and no Linux developer ever dreamed of having the same feature in Linux, but they kept struggling with standard futexes instead, and only now that some Windows-only game would benefit from this, then the Linux world wakes up and realizes how good this feature is?
Seems to me hard to believe, but I hope you prove me wrong.Last edited by lucrus; 26 November 2021, 11:52 AM. -
I mean, there's lots of stuff like this out there. Linux has inotify, which is way better in most practical situations than the equivalents on FreeBSD, macOS, and Windows. OpenBSD had the best random number facilities for years before they were copied. Copying good ideas is an ongoing process, WaitForMultipleObjects happens to be a good idea, probably IO_URING will get copied too..Originally posted by lucrus View PostComment
-
Absolebulutely! I mean, you aren't a real Windows gamer unless you're gaming on the really Big Iron.Originally posted by George99 View Post
Great to see these patches for both s390 and s390.
Comment
-
Having waitv interface for futex was first though of back in the day when futex was first implemented in Linux but no one managed to make it work good enough to have it mainlined so the whole idea was put on pause until the futex2 project brought it back to life.Originally posted by lucrus View Post
That said, remember also that Windows does not have a waitv interface for futexes, their WaitForMultipleObjects cannot wait for futexes and have a limit of max 64 objects per call. Windows also got futexes some 10 years after Linux, which didn't stop the bastards from filing a patent for it anyway...
And in the end this is a convenience function, its not that it was impossible to wait on multiple objects in Linux before, just that you had to write your own notification handler for it.Comment
-
Oh they are already at it with copying io_uring https://twitter.com/axboe/status/1396837335141134336 and lets not forget that they copied FUTEX from Linux some 10 years later (and patented it).Originally posted by microcode View PostComment
-
Unsure how it works but a quick glance at the risc-v code makes it look like it uses the generic syscall interface so it got it back when futex2 was added the first time.Originally posted by uid313 View PostComment
-
-
Basically the primary original intent/aim of this new API is WinAPI emulation, so no, it's not 'ahead of', it's just such API is widely used under Windows and emulating it gives too much overhead when emulated other ways.Originally posted by lucrus View PostComment
-
Oh lol, I guess I was right about what would happen, after it happened. Anyway, strengthens my point that there is still a lot of improvement to go around, and each popular userspace environment has some strengths to learn from.Originally posted by F.Ultra View PostComment
-
https://lwn.net/Articles/811696/ This is one of those tricky ones. 95% of futex_waitv can be done by eventfd but the there are problems. Like eventfd consuming file handles and not ending best performance. Yes file handles being a limited resource on Linux using eventfd for a Linux designed program is not too bad because the file handle limitation is designed for. Windows wait for multi objects is not a limited resource. This leads to the wine problem of round peg square hole.Originally posted by lucrus View Post
This is the problem Linux has had a close to the same feature as windows. Close enough people coding on Linux would mostly just code around the limitations to eventfd. Of course coding around the limitations means extra code so not the ideal performance at this point. Now windows programs under wine the application is not designed to expect limits in this area so you are stuffed.
This is right and wrong. There have been decades of people attempting to improve eventfd and other items to handle the same problem better. Yes the developers work on futex_waitv come from wine but this is not the first time attempting to solve the problem this is just the most recent. eventfd can implement a 95 percent feature match. Problem is that 5%.Originally posted by Alex/AT View Post
Yes those coding on Linux/Unix and BSD are use to the 5% missing. The reason funding the development of futex_waitv has been WinAPi emulation. The reasons of those reviewing the patches of futex_waitv for mainline are not all wine related. There have been a few changes to futex_waitv particularly for non wine use cases.
There has very much been we have a hammer so everything looks like nail. Yes eventfd and the other bits in the Linux kernel have been like using a hammer to drive in a screw (yes it does work as long as it lots and lots of taps) instead of using a screwdriver. Yes using a hammer to drive in screw does not end up with the best result in time either. So its not that the feature has been absolutely missing to Linux. Just the way Linux allowed doing the feature has horrible. Yes the horrible comes from the way Unix expect you to implement the feature remember the "everything is a file rule" of the Unix world (more guideline for how often in posix standard this is straight up broken). Futex break the everything is a file rule using a memory location.
Now windows with "everything is a object" rule means for particular problem is the screw driver. Do remember something here screwdriver yes just like a screw driver the windows idea when you have to drive in nails you are in trouble same is true with "everything is a object".
Yes this is why hammer and screwdriver is good examples here. Everything as a file and everything as a object both have their strict limitations. The ideal solution is going to be some middle ground between both ideas.
Also another thing to remember part of the reason for wine wanting to move to eventd and other items originally was to attempt to remove the need when using libwine of having to have wineserver. Wine goals don't just include emulation the project includes cross building its really simple to forget the winegcc bits.
wine="wine is not emulator" wine is not just an emulator is more correct. Its good to remember it this is a good way to remember when you use the word "emulation"/"emulator" with wine to explain why some change is being caused by wine that most of the time you will be missing half to all the picture of why something is happening.
Reduced dependence on wineserver is something long term futex_waitv will cause in wine and that a change for native building and emulation of windows binaries.
Comment
Comment