The point of trusted publishing is supposed to be that the public can verifiably audit the exact source from which the published artifacts were generated. Breaking that chain via a private repo is a step backwards.
There is a well-defined reload point—it’s the `subsecond::call` wrapper around `tick()`. But the hypothetical design that you seem to have in mind where this doesn’t exist would not have a well-defined reload point, so it would need to be able to preempt your program anywhere.
Layout changes are supported for structs that don’t persist across the well-defined reload point.
Yes, allowing this to execute would be very unsound:
let lock = RwLock::new(Box::new(111));
let r: &i32 = &**lock.read().unwrap(); // points to 111
*lock.write().unwrap() = Box::new(222); // allocates a new Box and deallocates 111
println!("{}", *r); // use after free
It can be done safely with an upgrade method that requires an owned read guard. The RwLock implementation provided by the parking_lot crate supports this safely:
let lock = RwLock::new(Box::new(111));
let read = lock.upgradable_read();
let r: &i32 = &**read; // points to 111
*RwLockUpgradableReadGuard::upgrade(read) = Box::new(222); // error[E0505]: cannot move out of `read` because it is borrowed
println!("{}", *r);
Of course (but that’s not relevant to the original scenario, where the programmer is hypothetically not aware that the read lock is still being held, let alone that they could manually upgrade it after changing to a different lock library).
The problem is that in the 'if let' case, the 'else' block has no access to the read guard. It's out of scope, except that the compiler hasn't dropped it yet.
Clippy already has an error for this pattern with Mutex. It should be trivial to extend it to cover RwLock.
error: calling `Mutex::lock` inside the scope of another `Mutex::lock` causes a deadlock
--> src/main.rs:5:5
|
5 | if let Some(num) = *map.lock().unwrap() {
| ^ --- this Mutex will remain locked for the entire `if let`-block...
| _____|
| |
6 | | eprintln!("There's a number in there: {num}");
7 | | } else {
8 | | let mut lock2 = map.lock().unwrap();
| | --- ... and is tried to lock again here, which will always deadlock.
9 | | *lock2 = Some(5);
10 | | eprintln!("There will now be a number {lock2:?}");
11 | | }
| |_____^
|
= help: move the lock call outside of the `if let ...` expression
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#if_let_mutex
= note: `#[deny(clippy::if_let_mutex)]` on by default
There are a lot of alternative lock implementations that are used all the time, with the most common ones probably being tokios RwLock/Mutex and parking_lot.
There are plenty of systems that sacrifice consistency even while the network is fully connected, in the name of performance—for example, DNS, or any system with a caching proxy server.
You’re certainly allowed to make the client a more active participant in your consensus protocol, but then it needs to play by the same rules if you want the system to have guarantees. For example, you need to handle network partitions between clients and some servers, and you need to be able to reconcile multiple reads from servers that might have seen different sets of writes. The CAP theorem still applies to the system as a whole.
They’re doing a slow phase-out over a long time to try to avert a wave of bad publicity that threatens their browser monopoly, but that timeline has already started as of June.
The mechanism is a clever application of quines (self-reproducing programs), first explained in the classic lecture “Reflections on Trusting Trust” by Ken Thompson:
And ICANN is bound by the IETF/ICANN Memorandum of Understanding Concerning the Technical Work of the IANA, which prevents it from usurping that jurisdiction:
https://docs.npmjs.com/generating-provenance-statements
https://packaging.python.org/en/latest/specifications/index-...
reply