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).
