[Issue 2757] New: resource management in a timely manner

Mar 24, 2009

d-bugmail

Mar 27, 2009

Apr 02, 2009

Apr 03, 2009

Apr 03, 2009

May 04, 2009

May 05, 2009

May 07, 2009

May 07, 2009

Aug 23, 2009

Aug 25, 2009

March 24, 2009

[Issue 2757] New: resource management in a timely manner

Posted by d-bugmail

Permalink

d-bugmail

Permalink

http://d.puremagic.com/issues/show_bug.cgi?id=2757

           Summary: resource management in a timely manner
           Product: D
           Version: 1.041
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: spec
          Severity: enhancement
          Priority: P3
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: nick.barbalich@gmail.com


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.

Thanks for the explanation, it really helps to keep this picture in mind.


--

http://d.puremagic.com/issues/show_bug.cgi?id=2757 maxmo@pochta.ru changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Comment #2 from maxmo@pochta.ru 2009-04-02 07:50 ------- This guy wants gc to free "unmanaged" resources each 10 seconds, because if gc objects, wrapping those resources, don't occupy much space, gc won't bother to collect garbage. --

d-bugmail@puremagic.com wrote: > > ------- Comment #2 from maxmo@pochta.ru 2009-04-02 07:50 ------- > This guy wants gc to free "unmanaged" resources each 10 seconds, because if gc > objects, wrapping those resources, don't occupy much space, gc won't bother to > collect garbage. The I suggest creating a thread that calls GC.collect() and then sleeps for ten seconds in a loop.

== Quote from Sean Kelly (sean@invisibleduck.org)'s article > d-bugmail@puremagic.com wrote: > > > > ------- Comment #2 from maxmo@pochta.ru 2009-04-02 07:50 ------- > > This guy wants gc to free "unmanaged" resources each 10 seconds, because if gc objects, wrapping those resources, don't occupy much space, gc won't bother to collect garbage. > The I suggest creating a thread that calls GC.collect() and then sleeps > for ten seconds in a loop. 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.

http://d.puremagic.com/issues/show_bug.cgi?id=2757 nick.barbalich@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Comment #3 from nick.barbalich@gmail.com 2009-05-04 06:14 ------- Why was this set to Status: Resolved & Resolution:Invalid ? --

http://d.puremagic.com/issues/show_bug.cgi?id=2757 ------- Comment #5 from nick.barbalich@gmail.com 2009-05-07 03:11 ------- (In reply to comment #5) > Because your solution doesn't solve even your problem. Perhaps you would like to propose a better solution ? My original request was have some mechanism (not defined) to release resources as soon as reasonably possible to prevent resource hogging. Perhaps if a object (e.g. buffer, lock, or handle etc) is defined, as a member of a resource pool, then a resource process will wake-up every x.xx seconds (as configured by the programmer) and remove any freed objects. The programmer should be able to define multiple resource pools. It would be desirable if the resource process could report how many resources had been freed, every wake-up, or a defined period of time. --

http://d.puremagic.com/issues/show_bug.cgi?id=2757 ------- Comment #6 from maxmo@pochta.ru 2009-05-07 06:28 ------- solution http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.bugs&article_id=16759 --

http://d.puremagic.com/issues/show_bug.cgi?id=2757 Bartosz Milewski <bartosz@relisoft.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bartosz@relisoft.com --- Comment #7 from Bartosz Milewski <bartosz@relisoft.com> 2009-08-23 14:44:31 PDT --- The problem of deterministic destruction can be solved by reference counting or uniqueness. Both may be implemented in the library. D2 will have full support for RAII using structs with the "postblit" operator, this(this). I am currently implementing a reference-counted thread handle and, as soon as compiler bugs are ironed out, I'll templatize it and put in the standard library. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

Forums