Implement mechanism to wait on any of several futexes

To me, it serves as a type of virtue signalling. It's kind of interesting to view the issue from a social perspective:

1. It gives a feedback to the committer, shows that your patch has caught the attention of a kernel maintainer, not lost or ignored (Example: last time, I sent a bunch of patches to a subsystem, no reply at all, it turned out that the maintainer was on a vacation. On the other hand, if I received a review on non-conforming code style, I know the maintainer is at least available, and I'm not rejected because I did something seriously wrong).

2. It gives kernel maintainers a chance to immediately expresses objections to your patch, thus affirming the social status and authority of a kernel maintainer (Example: After submitting a few patches, you'll quickly know who's in charge and who has a saying on the development).

3. By doing (2), it also creates a personal connection from the maintainer to the committer, the committer now knows all the sequentially modifications can be CC-ed to maintainer J. Random Hacker for review (although scripts/get_maintainer.pl should always be used, but at least you know who's the most active one).

4. It exerts peer pressure to the submitter to follow the cultural norms, "the system" of the kernel development process, including obeying the Linux kernel coding standard.

5. It creates a system of bureaucracy that could accelerate and mechanize the workflow of a patch-reviewing maintainer (Other examples include pull requests written in a formal, respectful language, often semi-automatically generated, can be compared to the bureaucracy paperwork, e.g. https://lore.kernel.org/lkml/20190731062622.GA4414@archbox/).

6. A lot of the older kernel code has many strange nonstandard coding styles and technical tricks from the early days, which is now discouraged. A strict coding style review prevents any nonstandard practice continues to enter the kernel as new code.

The act of expressing role and power through virtue signalling exists in all organizations. If "the system" itself serves its intended useful proposes without objectionable, serious harms [0], there is no reason to abolish it.

The only problem seems to be frustration over lengthy E-mail exchanges without progress. However, the workflow of Kernel is large, loose, highly asynchronous across different timezones, with a lot of reviewers, some are not even dedicated to the kernel project. Organizing itself already implies a relatively slow pace, so it's not seen as a major problem.

I believe most traditional FOSS project works more or less in the same way. In fact, I think Linux Kernel is actually a lot more open that other similar low-level projects, at least for the "non-core" (not linux-mm) parts, like device drivers.

Finally, I think there are valid criticisms to the traditional model of a FOSS project driven by mails, and many people have attempted to innovate towards a more accessible system of development. GitHub's "Pull Request" proved to lower the barrier-of-entry and boost productivity considerably for small-to-medium projects. And I welcome other innovations if you are starting a new project. On the other hand, the Linux Kernel is now a canonical representation of the "old system" which is very unlikely to change in the next 20 years. My recommendation is: Don't waste your energy to attack the old systems, instead, learn from all major projects and study their workflow and governance, and see if you can invent something new, we need a lot of innovation).

[0] Verbal abuses are criticized as a problem of this system, but by itself, it's not a part of the workflow, using what words is more closer that a matter of personal choice (so yes, one could say harsh criticisms is a greater problem in hacker culture, not only a workflow problem, it can be seen on mailing list, on online forums, IRC, or even offline). Also, Linus Torvalds recently changed his behavior under external pressure.

It could also be (c) -- it's correct but there's contention or: the mutex is too coarse / there's "too much" work being protected by the mutex.

But I think your point about matching windows is likely the case (this is how wine implements WaitForMultipleObjects maybe?). The fd exhaustion with FUTEX_FD means they need another way.

If the developer of the patch couldn't get the easy minor details right before submitting, I wouldn't have much confidence that they spent a lot of effort thinking about the hard, major details either.