Rust 1.78.0 released

Here's the problem: Rust has such a history of leadership dysfunction, that I have exactly zero confidence that this would be a useful thing for me to do. For all I know, I'll write a document, get mildly positive feedback, spend weeks or even months on implementation, and then get told "actually, we should've rejected this when you first proposed it, whoops, sorry." I get paid to put up with that sort of thing at $DAY_JOB. I'm not doing it in my free time.

Rust's leadership is aware of the problem. The difficulty is, they were already aware of it when keynotegate happened. They were, concurrent with that incident, already in the process of restructuring to make things more transparent, in the wake of the *previous* "leadership dropped the ball and miscommunicated something important" crisis. Given that backdrop, my position is that I'm not going to be interested in touching anything Rust that involves any degree of "figuring out what the solution should be" for at least another year, possibly longer if they manage to have another crisis, unless I'm getting paid to do so.

The Windows API in question did exist years ago, specifically more than a decade ago in Windows 8

> there are no emulation of futexes anywhere

I probably wouldn't call this "emulation" because of course the API you actually want isn't very negotiable, so Windows ends up with a very similar arrangement, but there are differences and if you want to call adapting to those differences, or even just the naming, "emulation" then that's what this does. For example:

pub fn futex_wait<W: Waitable>(futex: &W::Atomic, expected: W, timeout: Option<Duration>) -> bool {
// return false only on timeout
wait_on_address(futex, expected, timeout) || api::get_last_error().code != c::ERROR_TIMEOUT
}

> Rust had bug precisely because it doesn't want to repeat fate of Linux desktop.

Rust had this bug for the same reason the STL had this bug, because Microsoft is bad at software engineering as a practice and it routinely ships garbage. In this case the garbage isn't so bad that everybody noticed immediately... and so it was just left dormant for many years. Now, on supported Windows builds (and always on every decent OS) it does not have this bug.

When I say they're bad at engineering, this same incident provides an excellent demonstration. Rather than fix the bug in SRWLock, the preferred "solution" from that side of Microsoft was to document that this is just how that API worked, and everybody who has been using it (ie all C++, Rust and other downstream software) was doing it wrong. So they wrote that documentation change, and... it's stuck somewhere for weeks, their own autogenerated documentation doesn't work, nobody seems sure exactly why, but hey, they can close their "bug" ticket and too bad the published document is wrong, software doesn't work, everything is broken but at least the people who screwed up are rewarded...

This seems to surprise non-Windows people, but I've worked with Microsoft APIs before, so I'm used to it, broken garbage that's kept kinda-sorta working by people like Raymond Chen. "Oh yeah, always use values between 53 and 140 to make it work right". One of the first bits of work I did at my current job should just have mostly been a copy-paste of a Microsoft example, but it didn't work. Then I realised the example didn't work either. Plenty of Microsoft employees just don't even bother testing that their examples even work, they write something that sounds about right and hit publish, there is no verification step and there are no negative consequences if it's broken, you shipped, get your trophy. The results very much speak for themselves. That incident stuck in my head because I'd been writing a lot of Rust and appreciating the fact Rust's test automation *assumes your examples should work* and so your tests fail if you wrote a bad example. But probably Microsoft's tests don't pass either so...

As to the idea that somehow SRWLock is the correct idea and it's std::shared_mutex (or even sillier Rust's RWLock) that should be altered, this makes no sense. The reader-writer lock is a *really old* idea. It's in POSIX back when that mattered. Obviously the POSIX reader-writer locks, which is what Rust will use on a really crusty Unix with no futex, are slower, but they're not broken, they, unlike SRWLock, provide a useful reader-writer lock feature.

std::shared_mutex despite being newer than Windows 8 isn't "For compatibility with Windows 7" or something silly, it's the canonical way to write a reader-writer lock in pure standard C++ -- before that existed you'd either use platform APIs such as pthreads or you'd use a third party library or you'd go without. RWLock was in Rust 1.0 because duh, obviously you want a reader-writer lock, this is the 21st century.

You seem to just take the people who screwed up at their word that this is an optimisation. Is that how you'd feel in a similar situation for say, Linux filesystem APIs? "Oh of course the file close feature doesn't always close the file, it's an optimisation, people should know that closing a file might sometimes not close it". Without the optimisation, closing a file might close the file even if that was non-optimal somehow.

That's what is going on here. The "optimisation" in Microsoft's SRWLock as implemented is that if you try to take a reader lock, sometimes you silently have the writer lock instead, when you release it things will be back to normal, but meanwhile it's exclusively locked to you. So, if you needed (say) another of the readers to also take this lock, too bad they can't because it wasn't a reader lock after all. This is a crucial optimisation apparently, so crucial that it was unmentioned and nobody suspected it existed for over a decade. Also nobody else seems to have invented a similar optimisation on other platforms, and nobody else got excited and rushed off to implement it. "Weird".

I seriously doubt bug-to-bug emulation of Pulseaudio was a design target for Pipewire.

Perhaps you should leave this site then, too, and save us all your grandstanding?