41–50 of 142 posts
Earlier quoted context omitted.
> It is extremely difficult for programmer-users to report bugs against the Windows API I can't imagine living in this hell. When I find bugs in Linux, I E-mail the actual engineers directly and get responses in under 24 hours: https://lore.kernel.org/lkml/Zcb3_fdyJWUlZQci@gmail.com/
Microsoft engineers have emails too.
Subtle bugs in Reader/Writer locks do not surprise me. I worked on an in-house implementation based on Win32 (before C++11 and std::shared_mutex) and my recollection is that although the implementation sounds simple it is exceedingly easy to make subtle mistakes. The experience left me with such a bad feeling for shared locks that I tend to avoid them unless absolutely required. When I last tested std::shared_mutex,…
Earlier quoted context omitted.
This is an issue with a lot of MS products. I honestly have no clue how much money one would have to throw at MS to get a bug fixed. For example Microsoft's *own* Pluton-enabled platforms fail Windows' Device Health Attestation checks due to an incomplete chain ( https://call4cloud.nl/2023/04/are-you-there-intune-its-me-ha... ).
I've noticed a lot of big products have a user feedback cycle that goes something like this: - Create new feedback tracker - Direct feedback to tracker - Stop paying any attention to tracker - Tracker is hundreds of pages of users shouting into the void, and much of it out-of-date - Delete everything - Create new feedback tracker...
> It is extremely difficult for programmer-users to report bugs against the Windows API (we're supposed to direct you to Feedback Hub, but you may as well transmit your message into deep space). :'‑(
Earlier quoted context omitted.
This is an issue with a lot of MS products. I honestly have no clue how much money one would have to throw at MS to get a bug fixed. For example Microsoft's *own* Pluton-enabled platforms fail Windows' Device Health Attestation checks due to an incomplete chain ( https://call4cloud.nl/2023/04/are-you-there-intune-its-me-ha... ).
I've noticed a lot of big products have a user feedback cycle that goes something like this: - Create new feedback tracker - Direct feedback to tracker - Stop paying any attention to tracker - Tracker is hundreds of pages of users shouting into the void, and much of it out-of-date - Delete everything - Create new feedback tracker...
What you really need is a way to report problems which is high friction. You have to submit a git pull request of your ssh public key so you can transmit your bug report via sftp. Now they only get bug reports from people who can figure out how to do that and can actually pay attention to them because it filters out all the spam from people asking Microsoft how to connect their Android to a Mac.
Earlier quoted context omitted.
Microsoft engineers have emails too.
And how would you know what email to contact in a case like this one? It’s not about “having email”
Earlier quoted context omitted.
I've noticed a lot of big products have a user feedback cycle that goes something like this: - Create new feedback tracker - Direct feedback to tracker - Stop paying any attention to tracker - Tracker is hundreds of pages of users shouting into the void, and much of it out-of-date - Delete everything - Create new feedback tracker...
There's nothing worse than having a problem with a product, finding 250 other people on the feedback tracker that have had the same problem over the last three years, and the only official response is some support person on the first page who's saying your feedback is very important to us, and have you tried [troubleshooting that won't work]?
Once upon a time, you could buy various things from MS that came with support incidents. I had an MSDN subscription that came with two per year. Using an incident got you an actual support engineer who would be helpful and escalate issues if necessary. And, if your issue turned out to be a real bug of any significance in an MS product, your support incident would be credited back. This was great for developers (real…
Misleading title? This is a Windows API bug with the slim reader/writer (SRW) locks. It's just that the bug was discovered via std::shared_mutex as that is implemented using SRW locks. SRW locks: https://learn.microsoft.com/en-us/windows/win32/sync/slim-re... Confirmation from a Microsoft employee that the bug has been raised internally with the Windows API team: https://old.reddit.com/r/cpp/comments/1b55686/maybe_po…
Yes, for example if you make a Rust std::sync:RWLock on Windows, it will literally be SRWLock because Microsoft advertises this API as having exactly the behaviour Rust wants so why would you build something worse instead ? Rust's Mutex on Windows is also an SRWLock but it can't hit this bug because it deliberately only uses the exclusive locking.
Earlier quoted context omitted.
Yes, for example if you make a Rust std::sync:RWLock on Windows, it will literally be SRWLock because Microsoft advertises this API as having exactly the behaviour Rust wants so why would you build something worse instead ? Rust's Mutex on Windows is also an SRWLock but it can't hit this bug because it deliberately only uses the exclusive locking.
So it doesn't use a shared lock when .read() is used?