Reference count, don't garbage collect

Re:Reference count, don't garbage collect by btilly on Saturday July 30, 2022 @01:50AM (#32284588)

Consider an object referring to a network connection, say to a database. The object may be eligible for garbage collection but still have to respond to events from the network.

When it finally gets destroyed, its Destructor method would be called. At which point the thing at the other end of the network is told that it was talking to a zombie.

Note that network connections can be expensive for the other end, so this is a horrible design. We put a lot of work in to reliably get rid of connections when not needed. But you still need the fallback of being able to correctly handle programmer oversights.

[ Parent | on HN ]

Re:Reference count, don't garbage collect by mypalmike on Saturday July 30, 2022 @03:39AM (#32285046)

Yeah you can't apply C++ style resource management (specifically, calling close() in destructors or expecting cascading destructors to trigger in sequence) to GC languages. Object lifetime in a GC languages does not generally align with desired resource lifetimes. You have to be explicit. This often means creating your own public close methods when wrapping a resource in a class.

[ Parent | on HN ]