On 6/8/21 8:18 AM, Andrey Semashev wrote:
On 6/8/21 3:35 PM, Greg KH wrote:
On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
On 6/8/21 2:13 PM, Greg KH wrote:
So what's keeping the futex2 code from doing all that futex1 does so
that the futex1 code can be deleted internally?
I think, André will answer this, but my guess is, as stated above,
this is a
lot of work and time while the intermediate version is already useful.
useful to who? I still do not understand what users will be needing
this. All I can tell is a single userspace program wants to use it, and
that is a fork from the real project it was based on and that the
maintainers have no plan to merge it back.
So who does need/want this?
I mentioned C++ std::atomic and Boost.Atomic before. Those need variable
sized futexes.
The project you mention is probably Wine and its derivatives. Those need
variable sized futexes and "wait for multiple" operation. I'm not sure
about the "no plan to merge it back" part, I probably missed it in an
earlier discussion. There are multiple different patches and versions
out there, and I don't know which one it refers to. But WaitOnAddress
and WaitForMultipleObjects APIs are very important and I would assume
Wine wants to emulate those with best efficiency.
See [0]. The short version is that we can't use futexes the way that
out-of-tree patch set does, due to compatibility and robustness
problems. I wrote said patch set and I'm currently working on a
different solution for upstreaming.
We also can't exactly use futexes to back WaitOnAddress() directly. We
actually do currently, but for various complex reasons that needs to
change, and none of the proposals for futex2 help the new implementation.
ἔρρωσο,
Zebediah
[0]
https://lore.kernel.org/lkml/dab34fd2-b494-8686-bcd7-68beeba4f386@xxxxxxxxx/
