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.
