Bug 17563 – gc_inFinalizer should be public

Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P1
Component
druntime
Product
D
Version
D2
Platform
All
OS
All
Creation time
2017-06-27T16:21:31Z
Last change time
2019-12-19T19:21:40Z
Keywords
pull
Assigned to
No Owner
Creator
Steven Schveighoffer

Comments

Comment #0 by schveiguy — 2017-06-27T16:21:31Z
Currently there's a function gc_inFinalizer here: https://github.com/dlang/druntime/blob/master/src/core/memory.d#L150 This function allows one to tell inside a destructor whether the GC finalizer is running or not. This is currently the only way a destructor can tell whether it's in the GC finalizer stage or not (you should only access GC members if not inside the finalizer). A crude and horrible way to check for this is to try allocating inside the destructor, and catching the Error (an Error is thrown if inFinalizer is true). There's no reason we shouldn't just allow others to call this (they technically can already since it's extern(C)). It should be made part of the core.memory interface.
Comment #1 by aliloko — 2017-06-27T23:45:54Z
Note: This "crude and horrible way" helped me find plenty of bugs where I would rely on the GC to release a resource, and I only do this in debug clauses so it hardly really matter how ugly it is. It's a programming error, so I make it crash right away.
Comment #2 by schveiguy — 2017-06-30T13:35:52Z
ponce, it's not a slight against your mechanism. It's a problem with the API. There is no reason you should have to go through the hoops of attempting to allocate memory and catching an Error, just to check the value of a global boolean. Especially when there is already a function that does just that.
Comment #3 by safety0ff.bugz — 2017-09-13T02:44:29Z
An alternative solution worth considering is adding a parameter to destructors (e.g. ~this(bool gcfinalizer=false)) and have the compiler handle compatibility. The advantage is that it is a better interface for future/alternate GC sweep implementations. For example lazy/incremental sweep, concurrent sweep would need to use thread local variables to manage the status.
Comment #4 by dlang-bot — 2019-12-16T23:08:31Z
@PetarKirov created dlang/druntime pull request #2873 "Fix issue 17563 - Expose gc_inFinalizer" fixing this issue: - Fix issue 17563 - Expose gc_inFinalizer See the changelog entry and source code comments for details. https://github.com/dlang/druntime/pull/2873
Comment #5 by dlang-bot — 2019-12-19T19:21:40Z
dlang/druntime pull request #2873 "Fix issue 17563 - Expose gc_inFinalizer" was merged into master: - 63d86ee3525c40984307d57fb43db8939458856b by Petar Kirov: Fix issue 17563 - Expose gc_inFinalizer See the changelog entry and source code comments for details. https://github.com/dlang/druntime/pull/2873