The mistake there is a classical example of why (software) transactional memory is valuable. Double linked lists are trivial in single core execution, need PhD level understanding of everything in multicore execution and become trivial again in multicore execution with (S)TM.
Rust has troubles with STM because it lacks anything resembling effect system. Most probably, this will not be fixed.
Page 13 discuss why imperative approach like Rust's may fail in delivering transactional memory and why arbitrary-side-effect-free transactions in Haskell are, in fact, very composable due to effects separation inside STM and IO monads.
I hate this bot-detection anime girl popping up on my monitor while I pretend to be working. Same goes for the funny pictures at the beginning of some Github readmes. Sorry for complaining about a tangential annoyance, but I haven't seen this particular sentiment expressed yet.
I don't get why this is noteworthy? It's literally a piece of code in a Rust "unsafe" block. If you put something in an "unsafe" block the compiler isn't going to help you, you are on your own. That's why it's called "unsafe".
Now what is kinda interesting is that instead of getting rid of the "unsafe" block the developers put in some extra check. I guess you can take the developer out of C but you can't take the C out of the developer?
> Now what is kinda interesting is that instead of getting rid of the "unsafe" block the developers put in some extra check. I guess you can take the developer out of C but you can't take the C out of the developer?
The patch devs said that they're interested in larger-scale changes to get rid of the need for `unsafe` in this kind of situation, but since that'll take time it's more important to just fix the bug for now.
14 comments
[ 1.3 ms ] story [ 48.7 ms ] threadRust has troubles with STM because it lacks anything resembling effect system. Most probably, this will not be fixed.
Page 13 discuss why imperative approach like Rust's may fail in delivering transactional memory and why arbitrary-side-effect-free transactions in Haskell are, in fact, very composable due to effects separation inside STM and IO monads.
Instead of using this to do some proof of work, why not just get the bot detector to mine bitcoin or something...
I mean it is just as useless... And at least the website gets some money back from the raw extraction of data now happening...
Edit: speeeeeling
Now what is kinda interesting is that instead of getting rid of the "unsafe" block the developers put in some extra check. I guess you can take the developer out of C but you can't take the C out of the developer?
The patch devs said that they're interested in larger-scale changes to get rid of the need for `unsafe` in this kind of situation, but since that'll take time it's more important to just fix the bug for now.
[0]: https://lore.kernel.org/all/20251111-binder-fix-list-remove-...