www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A better way to check if the gc is running

reply bogdan <szabobogdan3 gmail.com> writes:
Hi,

When combining ref counting and GC allocated classes, weird bugs 
might happen. Is it possible to add a new member in 
`core.memory.GC`, like `isCollecting` or `isRunning`, to avoid 
testing if the GC is running, without allocating like this?

https://p0nce.github.io/d-idioms/#GC-proof-resource-class


Thanks,
Bogdan
Dec 12 2019
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 12 December 2019 at 08:56:37 UTC, bogdan wrote:

 Hi,

 When combining ref counting and GC allocated classes, weird 
 bugs might happen. Is it possible to add a new member in 
 `core.memory.GC`, like `isCollecting` or `isRunning`, to avoid 
 testing if the GC is running, without allocating like this?

 https://p0nce.github.io/d-idioms/#GC-proof-resource-class


 Thanks,
 Bogdan


I agree that this is a good idea. It shouldn't be hard to 
implement as the GC implementation already has this information 
available, so it's just a matter of exposing it through the 
layers.
Dec 12 2019
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-12-12 10:00, Petar Kirov [ZombineDev] wrote:


 I agree that this is a good idea. It shouldn't be hard to implement as 
 the GC implementation already has this information available, so it's 
 just a matter of exposing it through the layers.


In Tango for D1, Object has an additional method, `dispose`,  which is 
called by explicit `delete` or when the scope exists and the class 
variable is declared `scope`.

-- 
/Jacob Carlborg
Dec 14 2019
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On Thursday, 12 December 2019 at 09:00:38 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Thursday, 12 December 2019 at 08:56:37 UTC, bogdan wrote:

 Hi,

 When combining ref counting and GC allocated classes, weird 
 bugs might happen. Is it possible to add a new member in 
 `core.memory.GC`, like `isCollecting` or `isRunning`, to avoid 
 testing if the GC is running, without allocating like this?

 https://p0nce.github.io/d-idioms/#GC-proof-resource-class


 I agree that this is a good idea. It shouldn't be hard to 
 implement as the GC implementation already has this information 
 available, so it's just a matter of exposing it through the 
 layers.


https://issues.dlang.org/show_bug.cgi?id=17563

-Steve
Dec 15 2019
parent reply Bogdan Szabo <szabobogdan3 gmail.com> writes:
On Sunday, 15 December 2019 at 22:33:58 UTC, Steven Schveighoffer 
wrote:

 On Thursday, 12 December 2019 at 09:00:38 UTC, Petar Kirov 
 [ZombineDev] wrote:

 On Thursday, 12 December 2019 at 08:56:37 UTC, bogdan wrote:

 Hi,

 When combining ref counting and GC allocated classes, weird 
 bugs might happen. Is it possible to add a new member in 
 `core.memory.GC`, like `isCollecting` or `isRunning`, to 
 avoid testing if the GC is running, without allocating like 
 this?

 https://p0nce.github.io/d-idioms/#GC-proof-resource-class


 I agree that this is a good idea. It shouldn't be hard to 
 implement as the GC implementation already has this 
 information available, so it's just a matter of exposing it 
 through the layers.


 https://issues.dlang.org/show_bug.cgi?id=17563

 -Steve


This looks like an old issue, maybe we won't have this very 
soon... Is a DIP necessary for such changes?
Dec 16 2019
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 17/12/2019 2:23 AM, Bogdan Szabo wrote:

 On Sunday, 15 December 2019 at 22:33:58 UTC, Steven Schveighoffer wrote:

 On Thursday, 12 December 2019 at 09:00:38 UTC, Petar Kirov 
 [ZombineDev] wrote:

 On Thursday, 12 December 2019 at 08:56:37 UTC, bogdan wrote:

 Hi,

 When combining ref counting and GC allocated classes, weird bugs 
 might happen. Is it possible to add a new member in 
 `core.memory.GC`, like `isCollecting` or `isRunning`, to avoid 
 testing if the GC is running, without allocating like this?

 https://p0nce.github.io/d-idioms/#GC-proof-resource-class


 I agree that this is a good idea. It shouldn't be hard to implement 
 as the GC implementation already has this information available, so 
 it's just a matter of exposing it through the layers.


 https://issues.dlang.org/show_bug.cgi?id=17563

 -Steve


 
 This looks like an old issue, maybe we won't have this very soon... Is a 
 DIP necessary for such changes?


Only if it requires language changes (like adding a parameter to the 
destructor).
Dec 16 2019
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/16/19 8:23 AM, Bogdan Szabo wrote:

 On Sunday, 15 December 2019 at 22:33:58 UTC, Steven Schveighoffer wrote:

 On Thursday, 12 December 2019 at 09:00:38 UTC, Petar Kirov 
 [ZombineDev] wrote:

 On Thursday, 12 December 2019 at 08:56:37 UTC, bogdan wrote:

 Hi,

 When combining ref counting and GC allocated classes, weird bugs 
 might happen. Is it possible to add a new member in 
 `core.memory.GC`, like `isCollecting` or `isRunning`, to avoid 
 testing if the GC is running, without allocating like this?

 https://p0nce.github.io/d-idioms/#GC-proof-resource-class


 I agree that this is a good idea. It shouldn't be hard to implement 
 as the GC implementation already has this information available, so 
 it's just a matter of exposing it through the layers.


 https://issues.dlang.org/show_bug.cgi?id=17563


 
 This looks like an old issue, maybe we won't have this very soon... Is a 
 DIP necessary for such changes?


No. It's completely a library change, and backwards compatible.

-Steve
Dec 16 2019
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Monday, 16 December 2019 at 13:23:56 UTC, Bogdan Szabo wrote:


 [..]

 This looks like an old issue, maybe we won't have this very 
 soon... Is a DIP necessary for such changes?


Elapsed time is not always a good indication of the complexity or 
feasibility of a task, especially in open-source ;)

https://github.com/dlang/druntime/pull/2873
Dec 16 2019
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Monday, 16 December 2019 at 23:36:21 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Monday, 16 December 2019 at 13:23:56 UTC, Bogdan Szabo wrote:


 [..]

 This looks like an old issue, maybe we won't have this very 
 soon... Is a DIP necessary for such changes?


 Elapsed time is not always a good indication of the complexity 
 or feasibility of a task, especially in open-source ;)

 https://github.com/dlang/druntime/pull/2873


P.S. Thanks for reminding me of this issue Bogdan, sometimes 
communication is all that's necessary :)
Dec 16 2019
parent reply Bogdan Szabo <szabobogdan3 gmail.com> writes:
On Monday, 16 December 2019 at 23:38:15 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Monday, 16 December 2019 at 23:36:21 UTC, Petar Kirov 
 [ZombineDev] wrote:

 On Monday, 16 December 2019 at 13:23:56 UTC, Bogdan Szabo 
 wrote:


 [..]

 This looks like an old issue, maybe we won't have this very 
 soon... Is a DIP necessary for such changes?


 Elapsed time is not always a good indication of the complexity 
 or feasibility of a task, especially in open-source ;)

 https://github.com/dlang/druntime/pull/2873


 P.S. Thanks for reminding me of this issue Bogdan, sometimes 
 communication is all that's necessary :)


This is awesome!
Thank you for the fix!
Dec 17 2019
parent Guillaume Piolat <contact spam.org> writes:
On Tuesday, 17 December 2019 at 10:33:49 UTC, Bogdan Szabo wrote:

 On Monday, 16 December 2019 at 23:38:15 UTC, Petar Kirov 
 [ZombineDev] wrote:

 On Monday, 16 December 2019 at 23:36:21 UTC, Petar Kirov 
 [ZombineDev] wrote:

 On Monday, 16 December 2019 at 13:23:56 UTC, Bogdan Szabo 
 wrote:


 [..]

 This looks like an old issue, maybe we won't have this very 
 soon... Is a DIP necessary for such changes?


 Elapsed time is not always a good indication of the 
 complexity or feasibility of a task, especially in 
 open-source ;)

 https://github.com/dlang/druntime/pull/2873


 P.S. Thanks for reminding me of this issue Bogdan, sometimes 
 communication is all that's necessary :)


 This is awesome!
 Thank you for the fix!


+1 thanks a lot!
Dec 17 2019