That's the sort of thing I might say, yes, but only if your headspace is ready.
-
-
Replying to @erikcorry
Oh please, I have been already educated that Swift's ARC corrupting the heap under the race (just like GC Handbook predicted it should) is okay and should not be the cause for concern. Seeing a tracing GC designed to fail the similar way would be interesting.
1 reply 0 retweets 6 likes -
Replying to @shipilev
I did not know that! <the unplumbed depths of the human soul become visible> Apparently Go's memory safety in race conditions is "not a problem in practice" because they have a race detector.
3 replies 0 retweets 3 likes -
Replying to @erikcorry @shipilev1 reply 0 retweets 0 likes
-
Replying to @erikcorry @shipilev2 replies 0 retweets 0 likes
-
Replying to @erikcorry
Ugh. I wonder if this is still true today! Having critical metadata spanning multiple words is downright odd, and basically quality-of-implementation issue. Hotspot does a few sacrifices to avoid this (e.g. aligning objects by 8 to have aligned headers).
2 replies 0 retweets 1 like -
Replying to @shipilev @erikcorry
Separately, it is morbidly amusing how many think the worst case is segfault or some sort of security exploit. My nightmare is software corrupting (my medical, financial, personal) data and then persisting that corruption everywhere with no way to recover later.
5 replies 14 retweets 71 likes -
Replying to @shipilev @erikcorry
That is a good point. I should have made the argument about memory corruption instead of RCE 5 years ago in that thread.
1 reply 0 retweets 11 likes -
I thought that basically any language in existence had problems and races that can corrupt data and business logic. I know for example that Rust grants that even under a race you don't get memory corruption but data corruption is still there.
1 reply 0 retweets 0 likes -
You can't prevent people from using locks in a wrong way.
1 reply 0 retweets 2 likes
It’s a matter of degree. Rust makes it hard to misuse locks because you have to explicitly declare your synchronization semantics before the compiler will let you share data between threads. Java doesn’t require that, but still enforces memory safety. Go doesn’t.
-
-
The most common race that i see in code review is: Acquire readlock Make decisions Release readlock Acquire writelock Do smth based on previous decisions Release writelock Does Rust have smth to prevent that?
1 reply 0 retweets 1 like -
There are legitimate reasons you might want to do that, so no. But your example would often be more awkward than doing things the right way because you’d have to borrow multiple times. I haven’t seen that error much in Rust but I’m sure it happens. https://doc.rust-lang.org/std/sync/struct.RwLock.html …
0 replies 0 retweets 1 like
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.