Hacker News Reader

Comment by kevingadd | Hacker News Reader

Using automated resource management to drive socket (and handle, in general) lifetime is a terrible idea. Sometimes you really, really want to close a handle at a given time. The disposal of associated resources is another matter, and automating that is fine, but leaving a socket open 5 seconds too long is simultaneously 'correct' from a garbage collection perspective and totally, totally not the right thing to do.

The key observation here is that things like closing sockets are actual information channels, so tying them to implementation details like object lifetime is a terrible idea. This, concidentally, is why some attempts to tie the lifetime of long-running tasks/threads to object lifetime are a bad idea.

View on HN

There is no garbage collection in rust. There is no possible "five second gap".

Wherever you would have written "socket.close()", in rust you can just say "drop(socket)". The difference is, it takes advantage of the ownership system to statically prove that you won't try to use the socket after close.

Or just let it go out scope and it will be dropped immediately. NOT eventually garbage collected.

> Wherever you would have written "socket.close()", in rust you can just say "drop(socket)". The difference is, it takes advantage of the ownership system to statically prove that you won't try to use the socket after close.

Does a drop somehow say something to the type system as well, disallowing reads and writes afterwards? I'm new to rust, sorry if that's a stupid question.

In fact, the `drop` function is totally trivial. It's just a function that takes ownership of a thing, then does nothing with it whatsoever. In other words, the function body is entirely empty! :)

https://github.com/rust-lang/rust/blob/master/src/libcore/me...

Ha! I've been using this function for ages and always assumed it was a compiler built-in. I love that it's just that simple.

That's just too perfect. Of all things, your comment has raised my opinion of Rust the most.

> Does a drop somehow say something to the type system as well, disallowing reads and writes afterwards?

Yes.

I'm curious about the drop implementation, which I found here (http://doc.rust-lang.org/src/core/home/rustbuild/src/rust-bu...):

pub fn drop<T>(_x: T) { }

I understand that the drop function is simply taking ownership of the passed value so Rust knows that once "drop" finishes, the _x can be 'dropped'.

But I though that the T had to be bound to have "Drop" trait (i.e. T: Drop) so that Rust knows it's possible to insert the call to 'drop' like _x.drop()?

The names are a bit confusing here, and I might petition to change them.

The `drop` here is just a simple library function and isn't technically related to the `Drop` trait, which is implemented with magical compiler pixie dust and allows you to define a destructor via a `.drop` method. Anything that goes out of scope has this `.drop` method called automagically.

You're correct in that if you were calling `x.drop()` explicitly, you would need to have a `Drop` bound on `T`.

That's a good question.

If dropping was really implemented that way, every type would need to implement the Drop trait. Because otherwise there would be no way to free any memory at all.

Instead, Rust knows how to free any object. Implementing Drop is optional, and you only need to do it if you want some custom behavior at destruction.

Curious to know why `drop` isn't called automatically by the compiler as soon as possible (since the type system already seems to know it is safe).

Is there a trade-off involved here?

Freeing resources as soon as humanly (computerly?) possible will optimize your memory usage, but can actually be worse for execution speed. If you're willing to use slightly more memory, it's generally faster to free memory in coarse chunks than one-thing-at-a-time. So even though Rust can conceivably free memory sooner, it might as well defer freeing until the end of the scope, since it can prove that that's safe.

To take this to the logical extreme, see this awesome post from Walter Bright, where he doubles the speed of the D compiler by providing a custom malloc implementation that never frees, leaking all memory until the end of the process: http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over...

Thanks. I can see the pro in that choice. But the con would be memory starvation (assuming that heap is bounded as in the JVM).

I think one middle-path could be to mark the resource as released as soon as compiler detects it, and then release it

1. when the allocator is starved or

2. when the resource goes out of scope

3. when drop() is explicitly called

Heaps aren't bounded in systems contexts; a process is free to gobble up the entire address space if left unchecked, which would (hopefully) result in your process being killed by the OS.

I believe we have discussed your first bullet point there, with regard to attempting to free waiting-for-the-scope-to-end-but-not-being-used memory in the event that allocation fails. But this is a hairy subject, and is beyond my expertise.

Note that your third bullet point does cause memory to be freed immediately, because the `drop` function is a scope all its own.

One reason is probably emulating the way RAII works in C++, and allowing "low level" code to use idioms like

    {
        let _lock = acquire_lock();
        
        use_resource();
    } // lock is released here, whether use_resource() returned or caused stack unwinding

Makes a lot of sense: reduces generated code duplication. Just needs one "release" block per scope.

The other poster says it proves operations won't happen again - does it do both?

Yep! The owner of a thing can do the following:

1. Give ownership away to something else.

2. Free the object at the end of the scope.

In order to do anything to the object, you give up ownership to the function that does it (which can then give it back, if it doesn't need ownership of the value any more and doesn't want to free it itself). This even applies to the `drop` function, which just takes ownership and then does nothing whatsoever to the passed-in value, allowing it to go out of scope immediately. So once you've called `drop(foo)`, you no longer own the value and so can't give it away to any reading or writing function, and you can't drop it for the very same reason.

Just to be clear (and to check this myself -- I'm just starting to learn Rust), a five second gap is actually possible right? Say I use a socket, stop using it, don't call drop(socket), and I don't leave the scope for 5 seconds because I'm busy doing something.

Yeah, if you hold on to the thing in your scope, it won't go out of scope and won't be disposed of.

Yes, you are correct.

What I was trying to explain is that the timing is deterministic and immediate. People are used to unpredictable GC and rightly don't want to trust it with thing like this.

I have not used Rust before; does working with statistical analysis of runtime environments hinder debugging? In a multithreaded environment - does it pause the world for its runtime analysis or are there locks on shared resources representing ownership of individual objects, or does it do copies on writes of resources for idempotent operations as the references are moved around environment for lockless operations?

> does it pause the world for its runtime analysis

The borrow checker is _entirely_ at compile time.

To be fair, resource disposal is sometimes "delegated" to runtime. But it's always a local concern, like a reference counter for a shared resource, or a mutable `Option<R>` value that can have the R resource taken out of it or put back into it dynamically. There's no creepy overarching runtime system that tracks individual objects from a distance.

Yes, it's hard to figure out which way to talk about it. Rc<T> isn't really part of the borrow checker... it technically subverts it to do its own thing internally.

I wouldn't really consider the whole ownership thing or specifically the mechanism that inserts destructor calls at the logical end of a value's lifetime part of the borrow checker either, but I dunno how the implementation is laid out.

I agree. Having files and sockets close automatically is a bad pattern. Ideally, in a language with linear types, the compiler would notify you of all resources that you didn't properly dispose of when they go out of scope - so, unless you return the handle or call `close(f)` at the end of the function, you'd get a compiler error. The compiler could also auto-insert `close()`/`dispose()` methods when they go out of scope, as is implemented in Rust using the Drop trait.

I don't know if Rust supports forcing explicit deallocation, but even if it doesn't, it's still an improvement compared to most GC-d languages.

If I understand the borrowing and lifetime mechanisms of rust it would be trivial to have it say anything that has a lifetime that is active at the end of a scope is a compiler error.

It would almost be like how in c++ you can disable copying by setting all the copy constructors to delete and then the compiler will tell you if your accidentally making copy's of objects.

I agree, it would probably be trivial. It's mostly a language/library design issue, not a type-systems research problem.

You're talking about linear types, Rust implements affine types. They're very similar.

You can call drop() manually if you want it closed before the end of the scope, no harm, no foul.

Reply on news.ycombinator.com