Advice wanted on garbage collection of sockets for c++ programmer using D

[Guillaume Piolat via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer 
wrote:
> But I would use a close method, and not destroy(obj). The 
> reason is because often times, you have wrapper types around 
> your socket type, and just one extra level of indirection means 
> the destructor cannot be used to clean up the socket (you are 
> not allowed to access GC-allocated resources in a destructor).

All destructor restrictions do not apply when it's not called by 
the GC.

There really are two categories of destructors: called by the GC 
and called deterministically. Their usage should not overlap.




My reasoning went with the following:

1 - "I should have close() methods so that I don't rely on the 
GC, and the GC is calling ~this from the wrong thread etc, not 
everything can be released in this context (eg: OpenGL objects 
should be released from one thread only). Close methods will call 
close methods of "owned" objects."

2 - "Uh, oh. Refcounted and Unique and Scoped all use .destroy, 
so destructors should call close() methods. To avoid double 
release, close should handle being called several times. The GC 
will close what I forgot!"

3 - "Actually there is no order of destruction when called by the 
GC. So I can't release owned objects when called by the GC. 
Better do nothing when close() is called by the GC, let's detect 
this.

4 - close() is now identical with ~this (at least for classes). 
Let's remove the close() method. Crash when a resource is freed 
by the GC.

That's how the GC-proof resource class came to existence, after 
many destruction bugs, and it let's you use the GC as a detector 
for non-deterministic destruction. I miss it in @nogc :)

https://p0nce.github.io/d-idioms/#GC-proof-resource-class

Remember years ago when Alexandrescu suggested the GC shouldn't 
call heap destructors? That's what we get for having said no at 
the time.