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

[Moritz Maxeiner via Digitalmars-d-learn]

On Wednesday, 28 June 2017 at 12:33:24 UTC, Guillaume Piolat 
wrote:
> On Wednesday, 28 June 2017 at 11:34:17 UTC, Moritz Maxeiner 
> wrote:
>> Requirement: Do not allocate using the GC
>> Option 1) Use structs with `@disable this`, `@disable 
>> this(this)`, and a destructor that checks whether the resource 
>> reference is != invalid resource reference before trying to 
>> release.
>> Option 2) Use classes with simple constructor/destructor 
>> layout.
>> If you want to integrate a check that the requirement holds 
>> (with either class or struct), put `if (gc_inFinalizer) throw 
>> SomeError` into the class/struct destructor
>
> I don't get it.

You asked for a "_simple_ story about resource release" and the 
above two options provide that IMHO.

> It's completely possible to use the full power of GC and be 
> deterministic.

Sure, but it's not "simple". With D's GC as the memory allocator 
you can currently have
(1) non-deterministic memory management and non-deterministic 
object lifetimes:
     Use `new` or 
`std.experimental.allocator.make!(std.experimental.allocator.gc_allocator.GCAllocator)` for allocation&construction.
     The GC will finalize objects with no pointers to them 
non-deterministically and deallocate the memory after their 
respective finalization.
(2) non-deterministic memory management and deterministic object 
lifetimes:
     Construct the objects as with (1), but destruct them by 
calling `destroy` on them outside of a collection cycle (i.e. 
when they, and all their members are still considered "live" by 
the GC).
     The GC will collect the memory non-deterministically after 
there are no more pointers to it.
     Warning: You are responsible for ensuring that the GC will 
never see an undestroyed object in the collection cycle, because 
it might try to finalize (call its `~this`) it.
              You can protect yourself against such finalization 
attempts by putting `if (gc_inFinalizer) throw Error("Bug! I 
forgot to destruct!")` in the objects' respective destructors.
(3) deterministic memory management and deterministic object 
lifetimes:
     Construct the objects as with (1), but destruct&deallocate 
them by calling 
`std.experimental.allocator.dispose!(std.experimental.allocator.gc_allocator.GCAllocator)`on them outside of a collection cycle.
     The GC will not do anything for those objects.
     Same warning as (2) applies.

> I'm out of this very _confused_ discussion.

I'm honestly not sure what's confusing about it.