More radical ideas about gc and reference counting

Nick B via Digitalmars-d digitalmars-d at puremagic.com
Fri May 2 18:31:05 PDT 2014


[ monarch_dodra wrote ]  Well, that's always been the case, and 
even worst, since in a
dynamic array, destructor are guaranteed to *never* be run.



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


Resource Management.  A issue that has been discussed since 2009, 
and still no *GOOD* solution.


Look at these arguements made back then.


email 23 Mar 2009 from the D.d list. Subject : "Re: new D2.0 + 
C++ language".

Sat, 21 Mar 2009 20:16:07 -0600, Rainer Deyke wrote:

> > Sergey Gromov wrote:
>> >> I think this is an overstatement.  It's only abstract write 
>> >> buffers
>> >> where GC really doesn't work, like std.stream.BufferedFile. 
>> >>  In any
>> >> other resource management case I can think of GC works fine.
> > 
> > OpenGL objects (textures/shader programs/display lists).
> > SDL surfaces.
> > Hardware sound buffers.
> > Mutex locks.
> > File handles.
> > Any object with a non-trivial destructor.
> > Any object that contains or manages one of the above.
> > 
> > Many of the above need to be released in a timely manner. For 
> > example,
> > it is a serious error to free a SDL surface after closing the 
> > SDL video
> > subsystem, and closing the SDL video subsystem is the only 
> > way to close
> > the application window under SDL.  Non-deterministic garbage 
> > collection
> > cannot work.
> > 
> > Others don't strictly need to be released immediately after 
> > use, but
> > should still be released as soon as reasonably possible to 
> > prevent
> > resource hogging.  The GC triggers when the program is low on 
> > system
> > memory, not when the program is low on texture memory.
> > 
> > By my estimate, in my current project (rewritten in C++ after 
> > abandoning
> > D due to its poor resource management), about half of the 
> > classes manage
> > resources (directly or indirectly) that need to be released 
> > in a timely
> > manner.  The other 50% does not need RAII, but also wouldn't 
> > benefit
> > from GC in any area other than performance.


The language set up the defaults when these are to run.  The 
programmer has to override the defaults. [Sure this crude, but it 
deterministic]

[comment by dsimcha inm 2009 ] Come to think of it, as simple and 
kludgey sounding as it is, this is an incredibly good idea if you 
have an app that does a lot of sitting around waiting for input, 
etc. and therefore not allocating memory and you want an easy way 
to make sure it releases resources in a reasonable amount of 
time.  This belongs in
an FAQ somewhere.


More information about the Digitalmars-d mailing list