Rust means never having to close a socket • Hacker News Board

Re: Rust means never having to close a socket

#11

Post by dkhenry » Tue, Oct 07, 2014, 5:05 PM UTC

tomp wrote: post #7

kevingadd wrote: post #2

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. T…

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 s…

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.

Re: Rust means never having to close a socket

#12

Post by tomp » Tue, Oct 07, 2014, 5:08 PM UTC

dkhenry wrote: post #11

tomp wrote: post #7

Earlier quoted context omitted.

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 s…

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.

Re: Rust means never having to close a socket

#13

Post by rcthompson » Tue, Oct 07, 2014, 5:08 PM UTC

So in the first example, "from_file" is never used after the first call to "io::util::copy". Is Rust smart enough to realize that this is the last use of "from_file" and release it right then, or does it wait until it goes out of scope at the end of the function?

Re: Rust means never having to close a socket

#14

Post by illumen » Tue, Oct 07, 2014, 5:09 PM UTC

For files python[0] does not need an explicit with to close the file. It gets closed when references reach zero.

[0] For the pedants repeating each other in the replies... Where by python, I mean the implementation that 98% of people use, called python, which the competition calls CPython. Yes it is a great feature of the implementation, like the deterministic memory management through reference counting.

Re: Rust means never having to close a socket

#15

Post by steveklabnik » Tue, Oct 07, 2014, 5:11 PM UTC

tomp wrote: post #12

dkhenry wrote: post #11

Earlier quoted context omitted.

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.

Re: Rust means never having to close a socket

#16

Post by steveklabnik » Tue, Oct 07, 2014, 5:13 PM UTC

rcthompson wrote: post #13

So in the first example, "from_file" is never used after the first call to "io::util::copy". Is Rust smart enough to realize that this is the last use of "from_file" and release it right then, or does it wait until it goes out of scope at the end of the function?

Currently, borrows are lexical. We don't want them to be that way forever. https://github.com/rust-lang/rust/issues/6393

Re: Rust means never having to close a socket

#17

Post by Leon » Tue, Oct 07, 2014, 5:14 PM UTC

ef4 wrote: post #5

kevingadd wrote: post #2

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. T…

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.

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?

Re: Rust means never having to close a socket

#18

Post by zokier » Tue, Oct 07, 2014, 5:15 PM UTC

rcthompson wrote: post #13

So in the first example, "from_file" is never used after the first call to "io::util::copy". Is Rust smart enough to realize that this is the last use of "from_file" and release it right then, or does it wait until it goes out of scope at the end of the function?

There is ongoing discussion about this, eg here: https://github.com/rust-lang/rfcs/pull/239 (related reddit thread: http://www.reddit.com/r/rust/comments/2gs85u/rfc_allow_compi... )

Re: Rust means never having to close a socket

#19

Post by Leon » Tue, Oct 07, 2014, 5:16 PM UTC

pcwalton wrote: post #9

monocasa wrote: post #8

Earlier quoted context omitted.

> 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.

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

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

Re: Rust means never having to close a socket

#20

Post by wycats » Tue, Oct 07, 2014, 5:16 PM UTC

steveklabnik wrote: post #16

rcthompson wrote: post #13

So in the first example, "from_file" is never used after the first call to "io::util::copy". Is Rust smart enough to realize that this is the last use of "from_file" and release it right then, or does it wait until it goes out of scope at the end of the function?

Currently, borrows are lexical. We don't want them to be that way forever. https://github.com/rust-lang/rust/issues/6393

To be more specific, automatic dropping will likely always be scope-based. In the rare case where you need to drop something before its owning scope completes, you can explicitly use `drop` as people have said downstream.

Borrows are a different story. Especially with mutable borrows (which are basically a static lock on the value), the current lexical restriction is too coarse-grained. There are always workarounds, but it will be nice when it's fixed :)