Rust 1.61.0 released

Posted May 24, 2022 13:12 UTC (Tue) by atnot (subscriber, #124910)
In reply to: Rust 1.61.0 released by ballombe
Parent article: Rust 1.61.0 released

I'm not quite sure what that would entail, Rust doesn't really have "automatic memory allocation" much more than C does. You call some function, by convention called new/init/create to get a new object. This function might or might not call another function named malloc behind your back. When you're done, you call some function named free/delete/drop to clean it up.

The only thing Rust does slightly differently is that you can make it insert calls to your free/delete/drop function for you when something is truly (not just probably) no longer reachable. Otherwise things work exactly the same. I guess if you really wanted your code to look more like C, you could add a bunch of explicit drop calls at the end of your functions. But that seems a bit silly.

Rust 1.61.0 released

Posted May 24, 2022 16:00 UTC (Tue) by excors (subscriber, #95769) [Link] (1 responses)

> The only thing Rust does slightly differently is that you can make it insert calls to your free/delete/drop function for you when something is truly (not just probably) no longer reachable.

I think it's more accurate to put it the other way around: Rust will insert calls to the drop function according to quite simple rules (basically when the variable goes out of scope or has its value replaced, or when the object containing it is dropped, a lot like C++ destructors), and *then* it statically verifies that the object is not reachable through any references after that point (which is complicated and involves lifetimes and the borrow checker). In particular it's the opposite of automatic garbage collection, which first detects the object is definitely unreachable and then drops it.

(It's also worth noting that Rust doesn't guarantee that destructors will ever be called. E.g. std::mem::forget (https://doc.rust-lang.org/std/mem/fn.forget.html) will make an object unreachable without calling the drop function, and it's not an 'unsafe' function because memory leaks don't violate Rust's safety rules. You can also leak objects through Rc cycles etc. That's not common, and you're far less likely to accidentally leak than in C, but it is possible.

In particular it's tempting to design an API like "fn register<'a>(&self, callback: &'a T) -> Handle<'a>" which returns a Handle object whose lifetime cannot exceed the callback object that it was registered with. You might expect that to mean Handle::drop will be called before the callback is destroyed (so you can e.g. store a raw pointer to 'callback' in a global variable, then clear the global in Handle::drop) - and it's true that Handle::drop can't be called after callback is destroyed (the borrow checker will prevent that), but it might not be called at all if it's leaked, in which case the global was never cleared and is now a dangling pointer and violates safety when dereferenced, so you need to redesign your API.)

Rust 1.61.0 released

Posted May 27, 2022 15:06 UTC (Fri) by tbelaire (subscriber, #141140) [Link]

And a common way to redesign the api is to use an immediately called callback which provides to object you want to restrict, as while it's possible to forget handlers, it is not possible to fail to return. (Well, I guess you can loop forever, but you wouldn't be surprised that the resource is still used then). From crossbeam's documentation.

    let array = [1, 2, 3];

    crossbeam::scope(|scope| {
        for i in &array {
            scope.spawn(move || {
                println!("element: {}", i);
            });
        }
    });