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

[Guillaume Piolat via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer 
wrote:
> The GC still needs to call something to clean up non-memory 
> resources,

Well, I'd much prefer if the GC would simply not call 
destructors. Yes, destructor can work for _some_ resources, but 
because of ordering it also create accidental correctness, or 
just doesn't work with other resources.

> but having a call to use when cleaning up deterministically can 
> make resource management more efficient (even memory resource 
> management).

Yes. My point is that the destructor is uniquely positionned to 
be that call.
(This would also enables back failing destructors through the use 
of exceptions.)

In current D the problem with allowing the GC to close resources 
is that there is no ordering of destructors. A sub-tree of the 
ownership graph is freed by the GC together, but sometime an 
order is required for releasing.

Typically: you want to release a SDL_Texture but the Derelict 
SharedLib object has been freed already, so you can't call 
sdl_releaseTexture. It doesn't matter that the texture object 
held a reference to the ShareLib object since the sub-tree is 
destroyed together. close() methods don't help with that, the 
problem is with the GC calling destructors.


And if _some_ resource needs an ordering, then this property leak 
on their owners, so little by little the whole ownership graph 
need determinism.