Advice wanted on garbage collection of sockets for c++ programmer using D
Steven Schveighoffer via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Tue Jun 27 08:24:00 PDT 2017
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
> 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.
Yes, Tango solved this by having a separate "finalize()" method. I wish
we had something like this.
>
> 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."
I hadn't realized this, that is a good point. However, not all resources
are restricted this much.
> 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
There are definitely better ways to do this than trying to allocate and
catching an error. The GC knows the GC is running, use that mechanism
instead :)
> 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.
No, the issue is that there isn't a separate call for destruction and
GC. I think we should add this.
The GC still needs to call something to clean up non-memory resources,
but having a call to use when cleaning up deterministically can make
resource management more efficient (even memory resource management).
-Steve
-Steve
More information about the Digitalmars-d-learn
mailing list