Rust means never having to close a socket
blog.skylight.io
Rust means never having to close a socket
1–10 of 165 posts
Re: Rust means never having to close a socket
#2Using 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.
Re: Rust means never having to close a socket
#3Using 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…
You can call drop() manually if you want it closed before the end of the scope, no harm, no foul.
Re: Rust means never having to close a socket
#4C++11 introduces unique_ptr, which has a lot of the same safety characteristics. Rust's syntax does seem much nicer, though.
Re: Rust means never having to close a socket
#5Using 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.
Re: Rust means never having to close a socket
#6C++11 introduces unique_ptr, which has a lot of the same safety characteristics. Rust's syntax does seem much nicer, though.
> C++11 introduces unique_ptr, which has a lot of the same safety characteristics.
Sure, other than not actually being safe (UB resulting from use after move of unique_ptr being an obvious one; there are many others).
Re: Rust means never having to close a socket
#7Using 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 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.
Re: Rust means never having to close a socket
#8Using 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.
> 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.
Re: Rust means never having to close a socket
#9Earlier quoted context omitted.
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.
> Does a drop somehow say something to the type system as well, disallowing reads and writes afterwards?
Yes.
Re: Rust means never having to close a socket
#10C++11 introduces unique_ptr, which has a lot of the same safety characteristics. Rust's syntax does seem much nicer, though.
> C++11 introduces unique_ptr, which has a lot of the same safety characteristics. Sure, other than not actually being safe (UB resulting from use after move of unique_ptr being an obvious one; there are many others).
Good point! Safe if used very carefully, perhaps - like most of C++.