OSDev.org

This is another reply to this thread for it to be clean of unrelated stuff.


I see no arguments here, only some empty statements about your position. Can you elaborate why object scope is better than the exact code where the problem can emerge?

So, you suggest to rely on the default destructors and think no more (because everything else is "rare")?

Well, the word objectively is very impressive, but the arguments are missing again. Why we need some in/out channels when recovering after a problem? I prefer just to see the code, where the problem is going from, and concentrate on the exact situation the code produces. But you, it seems, prefer to concentrate on writing a very general destructors that match every possible problem in every possible situation. I just don't know how it is possible to write such very general destructors.

The only problem with exceptions is that they can be hidden by some poorly designed methods. But nobody can ignore the handling decision - everybody always decides to handle a problem or not to handle. Next, any complex state requires some serious thinking about it's recovery in case of a problem and ignoring such situation is really bad practice mostly employed by the very beginners. And finally, nothing prevents you (except some laziness) from extracting a function in case you see some repetitive code.

I can't oppose all those statements because I have no experience of working with Rust, but my general statement is the same - it's always up to the developer and his experience if the error handling is implemented correctly or not. The minor help from the language can improve a bit development speed, but generally is far from enough for not to expect some incorrect problem handling.

Checked exceptions always enforce the choice between handling them or passing them up along the calling stack, there's just no default, bad or good. And what is the "common choice" depends on the developer. If the language always enforces just one choice, then it is too inflexible and should be used with caution.

Well, when "rare" means "exclusively when calling unsafe foreign code", then yeah. See http://words.steveklabnik.com/a-30-minu ... on-to-rust (the 'ownership' section).

You rely on the compiler to do it for you - again, see the ownership section of the document linked above.

What is the point of your message? Is it the push for reading the introduction to Rust? The ownership section doesn't shed a light on the issue of "destructors can do all you need".

Well, is the compiler able to "write very general destructors that match every possible problem in every possible situation"?

Yes, the ownership section *does* shed light on this, and that *is* the point of my message.

See also http://blog.skylight.io/rust-means-neve ... -a-socket/:

All this text shows that the Rust requires a developer to allocate something, that can be used later, in heap memory instead of the stack. So, the stack memory is guarded against referencing from another function. But does Rust guard against a file system resource leak in case when files are referenced from the heap?

Yes. All resources exposed by the standard library, including files (both handle-based and memory-mapped) have destructors written for them, so no resource will ever leak. The only time developers write their own destructors is when they are also writing the code that directly does the allocation (calling malloc, fopen, etc.).

That's not true. Rust does not prevent reference count cycles which cause leaks of any resource (memory, files, etc.)

See http://smallcultfollowing.com/babysteps/blog/2015/04/29/on-reference-counting-and-leaks/

Correct. I should have said that no resource will leak just because you forget a finally block, because destructors are run automatically. This is not as strong a guarantee as a garbage collector as far as memory goes, but it is much stronger as far as non-memory resources go.

However, reference counting cycles are already a problem you have to deal with in systems programming, in the rare case that you can't use a better allocation strategy. They're also rather tangential to the problem embryo2 is talking about- finally blocks don't solve them either.

The problem is the moment when the destructor is called just missed here. How Rust determines there's no more need for a file (referenced from the heap)?

Rust uses the equivalent of C++'s unique_ptr and shared_ptr to keep track of heap references. Normally, when you allocate a "T" on the heap, you get a "Box<T>" which deallocates and calls the destructor in its own destructor. You can also use an "Rc<T>" for a thread-local reference-counted allocation, or an "Arc<T>" for a thread-safe atomically-reference-counted allocation.

There are other ways to allocate as well, such as "String," "Vec<T>," and "TypedArena<T>." They're all responsible for directly or indirectly calling the destructors of and deallocating their contents.

The heap is a red herring here. I can just easily open a file and forget to close it whether or not the file descriptor was on the stack or the heap.

This pattern of resource management is RAII: https://en.wikipedia.org/wiki/Resource_ ... ialization. The key idea is that holding a resource is tied to object lifetime. This ensures that as long as objects are properly destroyed (which is the responsibility of the language, for the most part), then resources (as defined by libraries, user code, etc.) will be released.

Well, I should ask again - how Rust determines that it should call Box's destructor?

So, I see the problem of determining when destructor should be called is still unsolved. It means (expectedly) there's no way to write a general destructor for all cases. And consequently, it means destructors suck when compared with a clear picture of allocation and deallocation of a resource within a code, that usually fits into one screen (yes, it's about try-catch-finally).

Under the chapter Benefits I see the following:

It clearly tells us about only one case - when resources are allocated on the stack.

Also, I suppose even the stack allocated resources aren't safe with Rust, because reference leak through a function, called from the object's creator function, is a thing that isn't easy to prevent.

This is because exception unwinding is unwinding the stack, so it will destroy any objects on the stack, it cannot destroy arbitrary objects. The idea is to bind the lifetime of a resource such as heap memory to an object (e.g. unique_ptr) which is held on a stack. That way if an exception occurs, then unwinding will cause the object on the stack to be destroyed which will in turn release the heap memory.


That is the whole point of lifetimes in Rust (you can read about this instead of guessing how it works). Every reference passed to a function has a lifetime associated with it which must be bound by the lifetime of the object to which it refers to. The compiler statically ensures that this is so.

Rust's Box<T> and C++'s unique_ptr<T> are allocated on the stack. They are just wrappers around a single pointer. Their destructor deallocates the actual T object on the heap, using the pointer they contain. And in Rust (unlike C++), references cannot leak. When you take a reference to something (e.g. passing a Box<T>'s pointer to a function accepting just a reference, or even taking the address of a variable on the stack), the compiler statically ensures that it cannot live longer than the value it points to.

Because all heap objects have an owner somewhere on the stack (directly or indirectly), and because borrowed references cannot outlive the things they point to, you only ever have to write each type's destructor once. Box<T> just has one destructor that frees the heap-allocated object, and it will always be called when returning from its stack frame.