www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Destructors vs. Finalizers

reply Mike Parker <aldacron gmail.com> writes:
Regarding the issue with `destroy` not being  nogc, I my 
understanding is it comes down to `rt_finalize` not being  nogc. 
I haven't dug too deeply into the discussions around it, but I'm 
wondering if it's possible to separate the concept of destruction 
from finalization in the implementation?

Externally, we can do it with the existing language:

class {
     ~this() {}     // Finalizer

     ~this  nogc {} // Destructor
}

Internally, the runtime will treat each differently. an 
rt_destruct would call all every __dtor in a hierarchy and 
rt_finalize would be changed to call every __finalizer (a new 
addition) in a hierarchy. When cleaning up, the GC will ensure 
that all destructors are run where they exist, followed by all 
finalizers. And destroy would be changed to call rt_destruct 
instead of rt_finalize.

Thoughts?
Jul 25
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
 Internally, the runtime will treat each differently. an 
 rt_destruct would call all every __dtor in a hierarchy and 
 rt_finalize would be changed to call every __finalizer (a new 
 addition) in a hierarchy. When cleaning up, the GC will ensure 
 that all destructors are run where they exist, followed by all 
 finalizers. And destroy would be changed to call rt_destruct 
 instead of rt_finalize.

 Thoughts?
And an important bit I left out -- destroy would still call rt_finalize if no destructor is present, which would preserve current behavior.
Jul 25
prev sibling next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
 Regarding the issue with `destroy` not being  nogc, I my 
 understanding is it comes down to `rt_finalize` not being 
  nogc. I haven't dug too deeply into the discussions around it, 
 but I'm wondering if it's possible to separate the concept of 
 destruction from finalization in the implementation?
Possible, yes, and I agree that separating destruction (deterministic end of object lifetime) and finalization (GC collection caused end of object lifetime) for classes is something we should do.
 Externally, we can do it with the existing language:

 class {
     ~this() {}     // Finalizer

     ~this  nogc {} // Destructor
 }
As class destructors (in contrast to class finalizers) are then called exclusively in a deterministic fashion, there's no reason to forbid them from allocating using the GC, so I don't think using the nogc attribute would be appropriate; I would much rather see another attribute in the likes of disable, e.g. deterministic, so --- ~this() {} // Finalizer ~this() nogc {} // Finalizer ~this deterministic {} // Destructor ~this nogc deterministic {} // Destructor } ---
 Internally, the runtime will treat each differently. an 
 rt_destruct would call all every __dtor in a hierarchy
As long as finalizers are then not part of __dtor.
 and rt_finalize would be changed to call every __finalizer (a 
 new addition) in a hierarchy.
 When cleaning up, the GC will ensure that all destructors are 
 run where they exist, followed by all finalizers.
Having the GC directly call destructors defeats the point of separating them from finalizers in the first place: If a destructor should be run on GC finalication, the finalizer must manually call the destructor (using e.g. `destroy`). The GC must *never* call destructors automatically after splitting off finalizers, because that would turn destructors back into finalizers.
 And destroy would be changed to call rt_destruct instead of 
 rt_finalize.
Yes, that would then be the correct behaviour for `destroy`.
Jul 26
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 26 July 2017 at 09:29:15 UTC, Moritz Maxeiner wrote:


 As class destructors (in contrast to class finalizers) are then 
 called exclusively in a deterministic fashion, there's no 
 reason to forbid them from allocating using the GC, so I don't 
 think using the  nogc attribute would be appropriate; I would 
 much rather see another attribute in the likes of  disable, 
 e.g.  deterministic, so
 ---
 ~this() {}                    // Finalizer
 ~this()  nogc {}              // Finalizer
 ~this  deterministic {}       // Destructor
 ~this  nogc  deterministic {} // Destructor
 }
Yeah, this brings with it more flexibility. I'd prefer to avoid adding a new attribute for it, but this looks more interesting.
 When cleaning up, the GC will ensure that all destructors are 
 run where they exist, followed by all finalizers.
Having the GC directly call destructors defeats the point of separating them from finalizers in the first place:
Indeed! Let's pretend I didn't write that.
Jul 26
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 26 July 2017 at 12:55:17 UTC, Mike Parker wrote:
 ---
 ~this() {}                    // Finalizer
 ~this()  nogc {}              // Finalizer
 ~this  deterministic {}       // Destructor
 ~this  nogc  deterministic {} // Destructor
 }
Yeah, this brings with it more flexibility. I'd prefer to avoid adding a new attribute for it, but this looks more interesting.
Some other options: ~~this() {} !this() {} !~this() {} this!(true) () {} //not really a big fan of this version
Jul 26
parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
 delete() {}
delete() {}

On Wed, Jul 26, 2017 at 3:08 PM, jmh530 via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Wednesday, 26 July 2017 at 12:55:17 UTC, Mike Parker wrote:

 ---
 ~this() {}                    // Finalizer
 ~this()  nogc {}              // Finalizer
 ~this  deterministic {}       // Destructor
 ~this  nogc  deterministic {} // Destructor
 }
Yeah, this brings with it more flexibility. I'd prefer to avoid adding a new attribute for it, but this looks more interesting.
Some other options: ~~this() {} !this() {} !~this() {} this!(true) () {} //not really a big fan of this version
Jul 26
prev sibling next sibling parent reply Guillaume Piolat <contact spam.com> writes:
On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
 When cleaning up, the GC will ensure that all destructors are 
 run where they exist, followed by all finalizers. And destroy 
 would be changed to call rt_destruct instead of rt_finalize.

 Thoughts?
I don't get the distinction between destructors and "finalizers" but imho the problem is very much that the GC is calling ~this.
Jul 26
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 26 July 2017 at 12:19:15 UTC, Guillaume Piolat 
wrote:
 I don't get the distinction between destructors and 
 "finalizers" but imho the problem is very much that the GC is 
 calling ~this.
Destructors are deterministic, finalizers are not. At least, that's how I understand the terms are commonly used.
Jul 26
parent reply Guillaume Piolat <contact spam.com> writes:
On Wednesday, 26 July 2017 at 12:35:19 UTC, Mike Parker wrote:
 On Wednesday, 26 July 2017 at 12:19:15 UTC, Guillaume Piolat 
 wrote:
 I don't get the distinction between destructors and 
 "finalizers" but imho the problem is very much that the GC is 
 calling ~this.
Destructors are deterministic, finalizers are not. At least, that's how I understand the terms are commonly used.
Note that Andrei once proposed in 2014 that the GC wouldn't call destructors/finalizers at all: http://forum.dlang.org/post/ljrm0d$28vf$1 digitalmars.com
 We're considering deprecating ~this() for classes in the future.
Instead the forum community pushed back and what has been done is extending the calls to GC-allocated structs.
Jul 26
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 26 July 2017 at 13:54:15 UTC, Guillaume Piolat 
wrote:
 On Wednesday, 26 July 2017 at 12:35:19 UTC, Mike Parker wrote:
 On Wednesday, 26 July 2017 at 12:19:15 UTC, Guillaume Piolat 
 wrote:
 I don't get the distinction between destructors and 
 "finalizers" but imho the problem is very much that the GC is 
 calling ~this.
Destructors are deterministic, finalizers are not. At least, that's how I understand the terms are commonly used.
Note that Andrei once proposed in 2014 that the GC wouldn't call destructors/finalizers at all: [...]
AFAICT that was mostly because it would have broken plenty of existing code. Properly separating destruction and finalization from each other with the current syntax remaining as finalizers and the new one for destructors would allow this to be done without major code breakage.
Jul 26
parent reply Guillaume Piolat <contact spam.com> writes:
On Wednesday, 26 July 2017 at 14:10:19 UTC, Moritz Maxeiner wrote:
 AFAICT that was mostly because it would have broken plenty of 
 existing code.
The validity or purposefulness of such code is up to debate, a separate debate granted. Let's assume there is working code that such a change will break.
 Properly separating destruction and finalization from each 
 other with the current syntax remaining as finalizers and the 
 new one for destructors would allow this to be done without 
 major code breakage.
Sure, in the event D would like to transition towards a state where the GC doesn't call finalizers, it seems useful. From a marketing point of view having two destructors and keyword/syntax just for this would be hard to defend, and it would also need to explain the whole story. Personally I'd be for: ~this() { /* deterministic one */ } void finalize() { /* the one called by GC */ } But then no transition path. I'll defend the view point that there is _nothing_ useful to do in a finalizer except to check if the destructor has already been called.
Jul 26
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/26/17 10:57 AM, Guillaume Piolat wrote:

 I'll defend the view point that there is _nothing_ useful to do in a 
 finalizer except to check if the destructor has already been called.
For instance, a destructor could destroy recursively all members at that time. A finalizer would not be able to. The thing to do in a finalizer that is useful is to release any non-GC resources. -Steve
Jul 26
parent reply Guillaume Piolat <contact spam.com> writes:
On Wednesday, 26 July 2017 at 15:15:03 UTC, Steven Schveighoffer 
wrote:
 On 7/26/17 10:57 AM, Guillaume Piolat wrote:

 I'll defend the view point that there is _nothing_ useful to 
 do in a finalizer except to check if the destructor has 
 already been called.
The thing to do in a finalizer that is useful is to release any non-GC resources. -Steve
Interesting case. Do we assume the finalizer is always called after the destructor? - If yes, then releasing these non-GC resources could have been possible in the destructor too. The only lost generality would be if releasing such non-GC resources would be faster from the GC thread (could well be since pooled). - else, it's a case of the finalizer being calld by the GC and the destructor not being called. Is this considered a bug? | | - If yes, then point of releasing resources is moot since we have a bug. | | - If not, it means we want to allow not calling destructors. | | | | => this implies we think finalizers will be called | | I'll make claim this works for process-wide resources somehow (we stopped the last debate here), but not transient ones (eg: mutex) because of false pointers. The finalizer might be released late. From these premises I conclude that the instructions given to new D programmers would be: 1. you should destroy resources deterministically 2. however GC objects owning resources may release them in their finalizer * except if you can't release them from any thread * except if these resources should be released before the GC shutdown (and then you have to explain why finalizer might not be called right now).
Jul 26
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/26/17 12:01 PM, Guillaume Piolat wrote:
 On Wednesday, 26 July 2017 at 15:15:03 UTC, Steven Schveighoffer wrote:
 On 7/26/17 10:57 AM, Guillaume Piolat wrote:

 I'll defend the view point that there is _nothing_ useful to do in a 
 finalizer except to check if the destructor has already been called.
The thing to do in a finalizer that is useful is to release any non-GC resources.
Interesting case. Do we assume the finalizer is always called after the destructor?
Yes, finalizer and destructor should be called on deterministic destruction (no need to repeat the finalizer code in the destructor).
 - If yes, then releasing these non-GC resources could have been possible 
 in the destructor too. The only lost generality would be if releasing 
 such non-GC resources would be faster from the GC thread (could well be 
 since pooled).
But the destructor can't be called from the GC. In cases where the GC is being used to clean up the object (whether on purpose or by accident), then if you didn't have a finalizer, the resource leaks.
 - else, it's a case of the finalizer being calld by the GC and the 
 destructor not being called. Is this considered a bug?
No.
 |
 |   - If yes, then point of releasing resources is moot since we have a 
 bug.
 |
 |   - If not, it means we want to allow not calling destructors.
Of course, the idea is that a destructor does what the GC would have done (recursively call the finalizers of members, and optionally clean up memory if wholly owned).
 |   |
 |   |   => this implies we think finalizers will be called
 |   |      I'll make claim this works for process-wide resources somehow 
 (we stopped the last debate here), but not transient ones (eg: mutex) 
 because of false pointers. The finalizer might be released late.
 
  From these premises I conclude that the instructions given to new D 
 programmers would be:
 
    1. you should destroy resources deterministically
 
    2. however GC objects owning resources may release them in their 
 finalizer
      * except if you can't release them from any thread
      * except if these resources should be released before the GC 
 shutdown (and then you have to explain why finalizer might not be called 
 right now).
Today, the finalizer is essentially a last-effort to clean up resources that would otherwise leak. The reason deterministic destruction sucks today is because once you go 2 levels deep, the only tool available (~this) cannot release any resources (because it's not legal to access GC-allocated members inside ~this). Adding a destructor concept would fix this issue, and make deterministic destruction more pleasant. Look at any library that contains such non-memory resources. These things inevitably implement some sort of "close()" or "release()" function, which does the deterministic destruction. It's just a destructor with a different name. -Steve
Jul 26
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 26 July 2017 at 22:29:50 UTC, Steven Schveighoffer 
wrote:
 Today, the finalizer is essentially a last-effort to clean up 
 resources that would otherwise leak.
My point is that this "last chance" to clean up resources should only be used to tell deterministic destruction wasn't acheived (for reasons given in my former post: it's _too hard to explain_ how to do resource management else).
 The reason deterministic destruction sucks today is because 
 once you go 2 levels deep, the only tool available (~this) 
 cannot release any resources (because it's not legal to access 
 GC-allocated members inside ~this).
You already know it, but if you commit to not doing anything in the finalizer case, then ~this doesn't suck, it works as a destructor and the restrictions lift. So "suck" is a bit strong.
 Look at any library that contains such non-memory resources. 
 These things inevitably implement some sort of "close()" or 
 "release()" function, which does the deterministic destruction. 
 It's just a destructor with a different name.
You could also merge the close() function with ~this() and remove ~this()-called-as-finalizer, which is the position I defend. If I count correctly there are 3 restrictions on the type of resource that can be GC-finalized: - can be destroyed from any thread - do not depend on another resource released by GC finalization, for it's own release https://forum.dlang.org/post/pmulowxpikjjffkrscct forum.dlang.org - can have a delayed finalization That's the reason why I thnk deterministic destruction for non-memory resources is easier than more mixed strategies.
Jul 27
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/27/17 4:23 AM, Guillaume Piolat wrote:
 On Wednesday, 26 July 2017 at 22:29:50 UTC, Steven Schveighoffer wrote:
 Today, the finalizer is essentially a last-effort to clean up 
 resources that would otherwise leak.
My point is that this "last chance" to clean up resources should only be used to tell deterministic destruction wasn't acheived (for reasons given in my former post: it's _too hard to explain_ how to do resource management else).
Consider reference counting with cycles. The proposal from Walter/Andrei is to do reference counting to clean up everything but cycles. For cycles, the GC will take care of it. So how do you do this correctly without having two separate mechanisms?
 The reason deterministic destruction sucks today is because once you 
 go 2 levels deep, the only tool available (~this) cannot release any 
 resources (because it's not legal to access GC-allocated members 
 inside ~this).
You already know it, but if you commit to not doing anything in the finalizer case, then ~this doesn't suck, it works as a destructor and the restrictions lift. So "suck" is a bit strong.
This is an unworkable solution. One simple time you forget to clean up deterministically and then you corrupt memory by using members that are already cleaned up. Or, you disable calling destructors in the GC, and instead leak resources. Or I suppose you could crash your application. This would be a fun bug to figure out... -Steve
Jul 27
next sibling parent Dgame <r.schuett.1987 gmail.com> writes:
 Consider reference counting with cycles. The proposal from 
 Walter/Andrei is to do reference counting to clean up 
 everything but cycles. For cycles, the GC will take care of it.
That is the PHP way to do things. :) It's neat but I still think the only real thing to deal with resources is built-in ownership like Rust does it. But that's a bit out of question for D2 I suppose. What's the state of the RC approach?
Jul 27
prev sibling parent Guillaume Piolat <contact spam.com> writes:
For cycle in RC you either do it like other RC system and break 
cycles manually, or create a parent owner to own every things 
pointing to each other and having cycles.

On Thursday, 27 July 2017 at 11:43:37 UTC, Steven Schveighoffer 
wrote:
 This is an unworkable solution.
Not at all unworkable, it's much easier than mixed strategies.
 One simple time you forget to clean up deterministically and 
 then you corrupt memory by using members that are already 
 cleaned up.
Once again, this is the reason of the existence of the GC-Proof-resource-class, which have the GC warn you of non-deterministic destruction at debug time. In the very case you mention it will tell you "you have forgot to release one resource T deterministically".
 Or, you disable calling destructors in the GC, and instead leak 
 resources.
As I said in previous messages, not all resources can be destroyed by the GC: they have to fit into 3 different constraints. I'll leave the discussion, you seem to ignore my arguments in what seems as an attempt to have the last word.
Jul 27
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 26 July 2017 at 14:57:14 UTC, Guillaume Piolat 
wrote:
 But then no transition path.
Does seem a bit like a nightmare... It may facilitate a transition to add a destructor member function as well (C# has dispose as an interface, maybe that's better?). Then have a deprecation for ~this and tell people to use finalize or destructor, and then add back ~this with the property that the default ~this calls destructor if that's there.
Jul 26
parent Guillaume Piolat <contact spam.com> writes:
On Wednesday, 26 July 2017 at 15:42:45 UTC, jmh530 wrote:
 On Wednesday, 26 July 2017 at 14:57:14 UTC, Guillaume Piolat 
 wrote:
 But then no transition path.
Does seem a bit like a nightmare... It may facilitate a transition to add a destructor member function as well (C# has dispose as an interface, maybe that's better?). Then have a deprecation for ~this and tell people to use finalize or destructor, and then add back ~this with the property that the default ~this calls destructor if that's there.
Well I like this idea best. To split C in A and B, deprecate C and tell what to do instead.
Jul 26
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/26/17 8:19 AM, Guillaume Piolat wrote:
 On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
 When cleaning up, the GC will ensure that all destructors are run 
 where they exist, followed by all finalizers. And destroy would be 
 changed to call rt_destruct instead of rt_finalize.

 Thoughts?
I don't get the distinction between destructors and "finalizers" but imho the problem is very much that the GC is calling ~this.
In D, the difference is when the thing is called. If it's called deterministically, either by function or by the compiler, then you have a lot more flexibility. If it's by the GC, it can be out of order with regards to your members, it could be on a different thread than the one that owned it, etc. Regarding the OP, I think we really should strive to have something to fix this issue. A poor-mans distinction could be done by checking whether the GC is currently the one destroying (a flag is available, but isn't publicly accessible), though that could get expensive. -Steve
Jul 26
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 26 July 2017 at 12:43:27 UTC, Steven Schveighoffer 
wrote:
 Regarding the OP, I think we really should strive to have 
 something to fix this issue.

 A poor-mans distinction could be done by checking whether the 
 GC is currently the one destroying (a flag is available, but 
 isn't publicly accessible), though that could get expensive.
That's essentially what Guillaume's "GC-proof resource class" idiom does now. https://p0nce.github.io/d-idioms/#GC-proof-resource-class
Jul 26
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/26/17 8:57 AM, Mike Parker wrote:
 On Wednesday, 26 July 2017 at 12:43:27 UTC, Steven Schveighoffer wrote:
 Regarding the OP, I think we really should strive to have something to 
 fix this issue.

 A poor-mans distinction could be done by checking whether the GC is 
 currently the one destroying (a flag is available, but isn't publicly 
 accessible), though that could get expensive.
That's essentially what Guillaume's "GC-proof resource class" idiom does now. https://p0nce.github.io/d-idioms/#GC-proof-resource-class
Yeah, I've seen that. https://issues.dlang.org/show_bug.cgi?id=17563 -Steve
Jul 26
prev sibling parent reply Dgame <r.schuett.1987 gmail.com> writes:
I don't get it. The GC collects the objects which aren't in use 
anymore. The order in which this is currently happening is not 
specified. So, how are the destructors supposed to be called in 
the right order? Manually? ARC? As far as I understand it, the GC 
can't do it, otherwise we wouldn't have the "random" order in 
which the finalizer are called in the first place.
Jul 26
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
 I don't get it. The GC collects the objects which aren't in use 
 anymore. The order in which this is currently happening is not 
 specified. So, how are the destructors supposed to be called in 
 the right order? Manually? ARC?
After the split: Destructors are only for deterministic end of object lifetime, so yes, they are to be called by any scheme (such as manual management via destroy and reference counting - which is likely also implemented as calling destroy) that is deterministic. Finalizers are for nondeterministic schemes such as the GC. The GC *never* calls destructors directly, only finalizers. A finalizer might manually call a destructor, but a destructor may never call a finalizer.
Jul 26
next sibling parent reply Dgame <r.schuett.1987 gmail.com> writes:
On Wednesday, 26 July 2017 at 18:33:58 UTC, Moritz Maxeiner wrote:
 On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
 I don't get it. The GC collects the objects which aren't in 
 use anymore. The order in which this is currently happening is 
 not specified. So, how are the destructors supposed to be 
 called in the right order? Manually? ARC?
After the split: Destructors are only for deterministic end of object lifetime, so yes, they are to be called by any scheme (such as manual management via destroy and reference counting - which is likely also implemented as calling destroy) that is deterministic. Finalizers are for nondeterministic schemes such as the GC. The GC *never* calls destructors directly, only finalizers. A finalizer might manually call a destructor, but a destructor may never call a finalizer.
Alright, thanks for the clarification. I've briefly hoped for some sort of miracle such as deterministic object lifetime without manual interaction. :)
Jul 26
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 26 July 2017 at 19:18:48 UTC, Dgame wrote:
 Alright, thanks for the clarification. I've briefly hoped for 
 some sort of miracle such as deterministic object lifetime 
 without manual interaction. :)
I'm not sure what scheme you are trying to describe here, could you give a code example of what you hoped for?
Jul 26
parent Dgame <r.schuett.1987 gmail.com> writes:
On Wednesday, 26 July 2017 at 20:02:02 UTC, Moritz Maxeiner wrote:
 On Wednesday, 26 July 2017 at 19:18:48 UTC, Dgame wrote:
 Alright, thanks for the clarification. I've briefly hoped for 
 some sort of miracle such as deterministic object lifetime 
 without manual interaction. :)
I'm not sure what scheme you are trying to describe here, could you give a code example of what you hoped for?
Built-in Ownership/RC for objects.
Jul 26
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
 On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
 I don't get it. The GC collects the objects which aren't in use 
 anymore. The order in which this is currently happening is not 
 specified. So, how are the destructors supposed to be called in the 
 right order? Manually? ARC?
After the split: Destructors are only for deterministic end of object lifetime, so yes, they are to be called by any scheme (such as manual management via destroy and reference counting - which is likely also implemented as calling destroy) that is deterministic. Finalizers are for nondeterministic schemes such as the GC. The GC *never* calls destructors directly, only finalizers. A finalizer might manually call a destructor, but a destructor may never call a finalizer.
Actually, it's the opposite. A finalizer can never call anything on its members because it doesn't know if it's being destroyed by the GC. The destructor is ensured that the entire structure is intact, so it can do whatever it wants. -Steve
Jul 26
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer 
wrote:
 On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
 On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
 I don't get it. The GC collects the objects which aren't in 
 use anymore. The order in which this is currently happening 
 is not specified. So, how are the destructors supposed to be 
 called in the right order? Manually? ARC?
After the split: Destructors are only for deterministic end of object lifetime, so yes, they are to be called by any scheme (such as manual management via destroy and reference counting - which is likely also implemented as calling destroy) that is deterministic. Finalizers are for nondeterministic schemes such as the GC. The GC *never* calls destructors directly, only finalizers. A finalizer might manually call a destructor, but a destructor may never call a finalizer.
Actually, it's the opposite.
It's a matter of definition and this is the behaviour I would define, because
 A finalizer can never call anything on its members because it 
 doesn't know if it's being destroyed by the GC.
This falsely assumes that all members point into the GC pool. A finalizer may freely work on non-pointer members and pointer members that target objects outside the GC pool which the programmer knows to be valid at finalization (e.g. they are manually managed). Whether or not it makes sense for the finalizer to call the destructor is something the programmer has to decide on a per use case basis.
 The destructor is ensured that the entire structure is intact, 
 so it can do whatever it wants.
The point is that I saw (and see) no reason for a destructor to ever call a finalizer.
Jul 26
next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 26 July 2017 at 23:28:38 UTC, Moritz Maxeiner wrote:
 This falsely assumes that all members point into the GC pool. A 
 finalizer may freely work on non-pointer members and pointer 
 members that target objects outside the GC pool which the 
 programmer knows to be valid at finalization (e.g. they are 
 manually managed).
* freely with the exception of not allocating using the GC, of course.
Jul 26
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/26/17 7:28 PM, Moritz Maxeiner wrote:
 On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer wrote:
 On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
 On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
 I don't get it. The GC collects the objects which aren't in use 
 anymore. The order in which this is currently happening is not 
 specified. So, how are the destructors supposed to be called in the 
 right order? Manually? ARC?
After the split: Destructors are only for deterministic end of object lifetime, so yes, they are to be called by any scheme (such as manual management via destroy and reference counting - which is likely also implemented as calling destroy) that is deterministic. Finalizers are for nondeterministic schemes such as the GC. The GC *never* calls destructors directly, only finalizers. A finalizer might manually call a destructor, but a destructor may never call a finalizer.
Actually, it's the opposite.
It's a matter of definition and this is the behaviour I would define, because
 A finalizer can never call anything on its members because it doesn't 
 know if it's being destroyed by the GC.
This falsely assumes that all members point into the GC pool.
Yes, I should have qualified GC members.
 A 
 finalizer may freely work on non-pointer members and pointer members 
 that target objects outside the GC pool which the programmer knows to be 
 valid at finalization (e.g. they are manually managed).
 Whether or not it makes sense for the finalizer to call the destructor 
 is something the programmer has to decide on a per use case basis.
No, because a destructor can safely assume it can look at GC members' data. So a finalizer can never call it.
 The destructor is ensured that the entire structure is intact, so it 
 can do whatever it wants.
The point is that I saw (and see) no reason for a destructor to ever call a finalizer.
An example: class File { int fd; ubyte[] buffer; // avoiding bikeshed issues by using clear names destructor() { finalizer(); delete buffer; } finalizer() { close(fd); } } No reason to repeat the finalizer code in the destructor. -Steve
Jul 26
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Thursday, 27 July 2017 at 00:00:08 UTC, Steven Schveighoffer 
wrote:
 On 7/26/17 7:28 PM, Moritz Maxeiner wrote:
 On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven 
 Schveighoffer wrote:
 On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
 A finalizer may freely work on non-pointer members and pointer 
 members that target objects outside the GC pool which the 
 programmer knows to be valid at finalization (e.g. they are 
 manually managed).
 Whether or not it makes sense for the finalizer to call the 
 destructor is something the programmer has to decide on a per 
 use case basis.
No, because a destructor can safely assume it can look at GC members' data. So a finalizer can never call it.
No, whether a finalizer can safely call a destructor depends on the destructor's body. If the destructor doesn't access GC members and doesn't allocate using the GC, the finalizer can safely call it. That's why it's the programmer's job to determine this on a use case basis.
 The destructor is ensured that the entire structure is 
 intact, so it can do whatever it wants.
The point is that I saw (and see) no reason for a destructor to ever call a finalizer.
An example: class File { int fd; ubyte[] buffer; // avoiding bikeshed issues by using clear names destructor() { finalizer(); delete buffer; } finalizer() { close(fd); } } No reason to repeat the finalizer code in the destructor.
I concede the point.
Jul 26
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/26/17 8:20 PM, Moritz Maxeiner wrote:
 On Thursday, 27 July 2017 at 00:00:08 UTC, Steven Schveighoffer wrote:
 On 7/26/17 7:28 PM, Moritz Maxeiner wrote:
 On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer wrote:
 On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
 A finalizer may freely work on non-pointer members and pointer 
 members that target objects outside the GC pool which the programmer 
 knows to be valid at finalization (e.g. they are manually managed).
 Whether or not it makes sense for the finalizer to call the 
 destructor is something the programmer has to decide on a per use 
 case basis.
No, because a destructor can safely assume it can look at GC members' data. So a finalizer can never call it.
No, whether a finalizer can safely call a destructor depends on the destructor's body. If the destructor doesn't access GC members and doesn't allocate using the GC, the finalizer can safely call it. That's why it's the programmer's job to determine this on a use case basis.
I suppose this is true, but in practice, you wouldn't in a destructor that which is available for a finalizer. In other words, you simply wouldn't implement such a destructor. It's also very fragile as the maintainer of the destructor is working under different assumptions from the finalizer. If you call the destructor from the finalizer, then the rules of the finalizer infect the destructor. -Steve
Jul 26
parent Swoorup Joshi <swoorupjoshi gmail.com> writes:
I might be hated for saying this but I still think the GC problem 
should not be apart of D language. Make it the user's or third 
party problem.
Jul 27