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

Re: Rust means never having to close a socket

#161

Post by anonbanker » Wed, Oct 08, 2014, 6:06 PM UTC

akavel wrote: post #149

shadowmint wrote: post #127

Earlier quoted context omitted.

I'm not arguing any of these points. I'm just saying there are these two misconceptions: - if you write safe rust code, your code can't segfault This isn't true if your code path contains any unsafe code. - Rust code can't segfault This isn't true at all . Sure, if it does segfault its a bug in the c code / unsafe code. You're absolutely correct. ...but bugs aren't deliberate. Obviously no one is going to deliberatel…

I don't understand -1s to the parent post; it's important to remember and be aware of limitations and dangerous areas in a language (or any other tool). And shadowmint tries to describe them in very civilized and calmly assertive way. I find his posts, as well as the counterarguments (like those from pcwalton and wycats), massively educative and informative. I absolutely can't understand why someone would like to see…

Upvoted grandparent based on this post.

Re: Rust means never having to close a socket

#162

Post by Derbasti » Wed, Oct 08, 2014, 8:21 PM UTC

Jweb_Guru wrote: post #160

Derbasti wrote: post #157

Earlier quoted context omitted.

Why? Wouldn't any garbage collector collect the file object when it goes out of scope? def foolish(): f = open('filename.txt') Once `foolish` returns, `f` goes out of scope, refcounting or not. Once `f` goes out of scope, its destructor closes the file. In CPython, the destructor is called when the refcount reaches zero. In Pypy, the destructor is called when there are no more references to `f`. Both happen when `foo…

Yes, you misunderstood how tracing garbage collection works. Cleanup of data allocated on the heap occurs during tracing phases, not when a reference goes out of scope. Otherwise, imagine if before it returned f copied the object into some global structure g--how would the garbage collector know it was safe to close? (Some garbage collected languages can do automated "escape analysis" to figure out whether an object…

How does that contradict what I was saying?

The garbage collector would still close the file eventually, right? Unless of course it was copied somewhere else in the meantime, but in the code example, that is clearly not the case.

Re: Rust means never having to close a socket

#163

Post by Jweb_Guru » Wed, Oct 08, 2014, 8:28 PM UTC

Derbasti wrote: post #162

Jweb_Guru wrote: post #160

Earlier quoted context omitted.

Yes, you misunderstood how tracing garbage collection works. Cleanup of data allocated on the heap occurs during tracing phases, not when a reference goes out of scope. Otherwise, imagine if before it returned f copied the object into some global structure g--how would the garbage collector know it was safe to close? (Some garbage collected languages can do automated "escape analysis" to figure out whether an object…

How does that contradict what I was saying? The garbage collector would still close the file eventually, right? Unless of course it was copied somewhere else in the meantime, but in the code example, that is clearly not the case.

Eventually, yes. But if you're relying on the file being deterministically closed (e.g. if you're using the POSIX file locking mechanism) in CPython, it won't necessarily be correct in non-reference counting garbage-collected languages, and the same is true if you're relying on any other sort of deterministic resource cleanup (e.g. in memory-constrained environments).

Re: Rust means never having to close a socket

#164

Post by chetanahuja » Thu, Oct 09, 2014, 4:29 PM UTC

pjmlp wrote: post #145

chetanahuja wrote: post #113

Earlier quoted context omitted.

"Granted, I have no idea how much overhead is imposed by atomic operations vs. a stop-the-world or concurrent GC." An atomic read/write/increment/decrement is a non-blocking (from the point of the view of a user code running on the CPU) CPU operation. The CAS operations required to do atomic inc/dec are relatively expensive compared to normal memory read/writes of course but nowhere near the scale of stop-the-world G…

That is an implementation issue. There are plenty of JVMs to choose from, even pauseless ones.

Hah.. Implementation issue. That's a good one. It's just like an SUV not being landmine proof is an implementation issue. Just because somewhere a landmine proof humvee exists doesnt mean its attainable or practical for an ordinary user.

Re: Rust means never having to close a socket

#165

Post by rcthompson » Fri, Oct 10, 2014, 6:17 PM UTC

wycats wrote: post #20

steveklabnik wrote: post #16

Earlier quoted context omitted.

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

Is there a specific reason for automatic dropping to be scope-based? Is it because dropping things could have side effects (e.g. closing a filehandle) and scope-based dropping makes it easy for someone looking at the code to determine when these side effects will occur?