Hacker News Reader

Comment by wycats | Hacker News Reader

What happens if there's a cycle? It will get closed when the cycle is finally collected.

You can rely on a GC (and refcounting + a cycle collector is absolutely a GC) to finalize your resources for you, but it is quite difficult to reason about when the file will eventually be closed.

Also, the reference counting semantics of CPython are implementation-specific. From the PEP that introduced `with`:

> Note that we're not guaranteeing that the finally-clause is executed immediately after the generator object becomes unused, even though this is how it will work in CPython. This is similar to auto-closing files: while a reference-counting implementation like CPython deallocates an object as soon as the last reference to it goes away, implementations that use other GC algorithms do not make the same guarantee. This applies to Jython, IronPython, and probably to Python running on Parrot.

View on HN

Props to Rust for tackling this head on, more languages should provide resource allocation that's deterministic, predictable and syntactically convenient.

CPython's behavior is nice, but it seems to me it came about by accident. Big heavy resources use refcounting because everything uses refcounting. Plus, if CPython had true concurrency, across-the-board refcounting probably wouldn't have lasted nearly as long (reason being: multithreaded refcounting requires atomic ops which make them much more expensive).

But in the general language design world, IMHO, refcounting is actually a pretty good compromise for resource management. Because:

1) The efficiency lost compared to Rust's approach is probably immaterial (since the Big Expensive Object that you're mananaging dwarfs the refcounting -- syscalls and file descriptors are expensive). So I don't think zero overhead is critical.

2) Cycles are pretty easy to avoid when you're only refcounting Big Expensive Objects (FDs, mmapped buffers, etc. etc.) For a general runtime, refcounting is tricky. But if it's a special part of the language that's small, simple, and only for resource management, it's pretty convenient. I think it's worlds better than the approach of mixing GC and resource management -- language designers should admit that's a terrible idea.

I agree that refcounting is a great and usable compromise in this space, but your own comment flirts with why I don't think modern languages are chomping at the bit to base resource management on it: concurrency.

Granted, I have no idea how much overhead is imposed by atomic operations vs. a stop-the-world or concurrent GC (if anyone has some data, I'd love to see it!). But given how it's become de rigeur for new languages to come with a baked-in concurrency story and emphasize concurrent applications, I don't blame them for not wanting to tie themselves to the RC cart.

"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 GC (where all threads in the runtime have to be blocked for a potentially large amount of time, sometimes measured in whole seconds or even 10's of seconds for large heaps).

Anyone who has had to troubleshoot JVM's handling large heaps (in the ~10GB range) quickly learns to love deterministic costs of refcounted resource management.

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: threads uber ref-counting.

Hit one of my hot-buttons: Threads have got to be one of the most massive WOMBAT boondoggles of the last few decades.

Pro) none of this slow inter-process-communication stuff!

Con) EVERYTHING is now dangerous. (not quite, but close)

But the industry (?) decided "TOTALLY worth it!"

I forgot to mention that threads start a little faster than processes (well, quite a bit faster on a particular shitty OS in widespread use), but not so much faster that you won't need to pool and re-use the threads anyway. I think this is one area where Erlang (actor pattern), for instance, gets it right: pretend tasks run in their own process, and use an IPC proxy to send messages between the tasks/sub-programs, even if implemented with threads instead of OS level processes.

CPython is the implementation that 98% of the market uses, but you are partially correct for that other 2%.

You are also wrong for CPython which does NOT require the garbage collector to be on, and DOES release the file in a deterministic way.

Simply, the article is misleading with regards to python.

Still, do you want to bake assumptions based on CPython's implementation into your codebase, then have those assumptions invalidated when you later switch to PyPy to take advantage of the JIT compiler?

If the garbage collector were turned off and a cycle were to be present, the file would simply never be closed. Though I suppose that would, indeed, be deterministic.

Reply on news.ycombinator.com