Joder con el nivel del FP. Que en Fundamentos de la programacion se da esto:
A thread-safe reference-counting pointer. ‘Arc’ stands for ‘Atomically Reference Counted’.
The type Arc<T> provides shared ownership of a value of type T, allocated in the heap. Invoking clone on Arc produces a new Arc instance, which points to the same allocation on the heap as the source Arc, while increasing a reference count. When the last Arc pointer to a given allocation is destroyed, the value stored in that allocation (often referred to as “inner value”) is also dropped.
Shared references in Rust disallow mutation by default, and Arc is no exception: you cannot generally obtain a mutable reference to something inside an Arc. If you need to mutate through an Arc, use Mutex, RwLock, or one of the Atomic types.
Thread Safety
Unlike Rc<T>, Arc<T> uses atomic operations for its reference counting. This means that it is thread-safe. The disadvantage is that atomic operations are more expensive than ordinary memory accesses. If you are not sharing reference-counted allocations between threads, consider using Rc<T> for lower overhead. Rc<T> is a safe default, because the compiler will catch any attempt to send an Rc<T> between threads. However, a library might choose Arc<T> in order to give library consumers more flexibility.
Arc<T> will implement Send and Sync as long as the T implements Send and Sync. Why can’t you put a non-thread-safe type T in an Arc<T> to make it thread-safe? This may be a bit counter-intuitive at first: after all, isn’t the point of Arc<T> thread safety? The key is this: Arc<T> makes it thread safe to have multiple ownership of the same data, but it doesn’t add thread safety to its data. Consider Arc<RefCell<T>>. RefCell<T> isn’t Sync, and if Arc<T> was always Send, Arc<RefCell<T>> would be as well. But then we’d have a problem: RefCell<T> is not thread safe; it keeps track of the borrowing count using non-atomic operations.
In the end, this means that you may need to pair Arc<T> with some sort of std::sync type, usually Mutex<T>.
Breaking cycles with Weak
The downgrade method can be used to create a non-owning Weak pointer. A Weak pointer can be upgraded to an Arc, but this will return None if the value stored in the allocation has already been dropped. In other words, Weak pointers do not keep the value inside the allocation alive; however, they do keep the allocation (the backing store for the value) alive.
A cycle between Arc pointers will never be deallocated. For this reason, Weak is used to break cycles. For example, a tree could have strong Arc pointers from parent nodes to children, and Weak pointers from children back to their parents.
#22919 No, hoy estamos en programacion de "bajo nivel" o manual memory management. y por lo visto en /dev la gente sue;a en compilador y programa en C sin stackoverflows ni corromper memoria. al toque.
