4 ms·
The very short version: There are many things which cause both frequent and rare strange crashes in multi-threaded code. In C, all these things will compile O
by gridspy 6y ago
The very short version:
There are many things which cause both frequent and rare strange crashes in multi-threaded code.
In C, all these things will compile OK.
In safe Rust, practically none of them will compile.
It is much easier to fix compile issues in Rust to do with dangerous memory usage or thread sharing than it is to debug a compiled program.
- pjmlp 6y agoAccessing files or database content from multiple threads without proper locking, or transactions, in place will compile just fine.
- bluejekyll 6y agoRust won’t prevent all manner of bugs, but if you need to prevent multiple parts of your application from accessing a resource concurrently, it’s fairly trivial to design types that would guarantee that at compile time. If you need to do it across processes, then you need a file system that supports exclusive file opens. The db question is a red-herring, because to properly solve for concurrency in the db, you need to use locks in the db (table and row locks), not the code accessing the db.
- Chilinot 6y agoYou dont necessarily need to use locks in the db. You can use transactions as well, unless you want to do major changes to the DB where transactions would be in constant conflict state.
- bluejekyll 6y agoYou’re right, though that wasn’t really the point of my reply. More that concurrency in the DB is a DB design choice and not the responsibility of the language accessing the DB. This is especially true when accessing the DB from multiple nodes, which most deployed software does.
- branko_d 6y agoLocks and transactions are intertwined. Write locks are typically released only when the transaction ends, and read locks too at some transaction isolation levels.
- pjmlp 6y agoIndeed, but the fearless concurrency sales pitch tends to overlook that.
- ben0x539 6y agoThe fearless concurrency sales pitch doesn't overpromise. You're trying to stretch it, but it's pretty clear on what kind of concurrency issues it covers (eg. data races).
- hderms 6y agoYeah it would be a grave misinterpretation of "fearless concurrency" to think Rust somehow validates that access to some shared resource with it's own semantics is also safe. I'm not educated on the subject but that problem seems pretty intractable for a language to solve in a general sense.
- pjmlp 6y agoIndeed, yet that is not how many Rust advocacy blog posts sell it.
- shakow 6y agoSuch as?
- pjmlp 6y agoAny blog post that gives examples accessing shared variables and never goes beyond anything else, leaving to the reader that it works the same way regardless of what resources are being accessed. https://blog.knoldus.com/how-we-can-do-fearless-concurrency-in-rust/ https://blog.knoldus.com/how-we-can-do-fearless-concurrency-... Now rewrite the same blog post using SQL queries to update the same counter variable on a table row. The Rustonomicon is quite clear that it wouldn't work, > However Rust does not prevent general race conditions. https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html
- masklinn 6y ago> Rust won’t prevent all manner of bugs Nit: rust will prevent all manner of bugs. Rust won't prevent every manner of bugs.
- simias 6y agoRust has the expressive power to design an API that explicitly makes it impossible if you so desire though. For instance by using an API similar to mutexes where you have to lock to access the contents.
- pjmlp 6y ago> However Rust does not prevent general race conditions. https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html
- simias 6y agoI never claimed otherwise. If you want to enforce invariants in your DB API you'll have to implement them yourselves, Rust won't do it for you because Rust doesn't know what a database is. Still, it's perfectly possible to design a DB API is such a way that it would prevent some issues, such as for instance doing changes without an active transaction. But you're right to point out that Rust won't magically solve all your possible sources of crash and data corruption, it just does make it a lot easier to enforce arbitrary constraints. For instance if you decide that in order to avoid these issues you want all your DB stuff to only run in a single thread you could design your API in a way that would prevent DB handles from being shared between threads, all that enforced by the language. You couldn't accidentally leak a DB handle to a different thread.
- orf 6y agoWhat a silly point to make. The code you’re writing in rust could launch a nuke that destroys the world and it will also compile just fine.
- masklinn 6y ago> Accessing […] database content from multiple threads without proper locking, or transactions, in place will compile just fine. All the rust db interfaces I've seen so far forbid unlocked sharing of connections, statically (the connections are !Sync, in Rust speak).