Hacker News new | ask | show | jobs
by DanWaterworth 2804 days ago
If you are consuming an API that provides an object with a destructor, you are correct, you can determine when destructors will be called.

The issue is when you produce an API that contains objects with destructors. Since you are handing these entities off to unknown code, you cannot ensure that they will be dropped. This was a problem in scoped threads in Rust.
1 comments
siscia 2803 days ago
Can you please dig deeper, that I am not sure I follow.

In which case in rust you cannot be sure that "the drop" will be called?

link
dbaupp 2803 days ago
If there's a cycle of strong references with Rc or Arc (or shared_ptr in C++), those objects still never get dropped/have their destructors called.
link
zaphar 2803 days ago
Rc's drop will be called. But whether the exposed object's drop will be called is dependent on the reference count.

But Rc would not work if the drop was not guaranteed to be called.

link
dbaupp 2803 days ago
I was a little unclear but that is of course what I meant: talking about the underlying shared data because the pointers themselves don't have particularly interesting destruction behaviour. (Although the sibling is also correct that not all Rc/Arc/shared_ptr handles to the shared data with have their Drop called.)
link
steveklabnik 2803 days ago
If you have a reference cycle, the two Rcs will keep each other alive, and their Drops will not be called.
link
quietbritishjim 2803 days ago
I think that falls into the category I mentioned in the third paragraph of my comment: a serious pre-existing bug with other consequences will potentially cause the guarantee to be violated. A similar effect would happen if you had a double free that sometimes caused a crash, which is a similar level of programming mistake to creating a cyclic reference. To me it sits outside of a reasonable definition of "guaranteed".
link
dbaupp 2803 days ago
No, typically, a reference cycle is fine. It results in valid memory that never gets read again, which is unfortunate but not dangerous, whereas double-frees can result in memory corruption. http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-...
link
richardwhiuk 2803 days ago
A Rc cycle causing a leak.

See the very excellent http://cglab.ca/~abeinges/blah/everyone-poops/

link