www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2757] New: resource management in a timely manner

reply d-bugmail puremagic.com writes:
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. --
Mar 24 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2757





------- Comment #1 from bugzilla digitalmars.com  2009-03-27 03:38 -------
What is the enhancement request?


-- 
Mar 27 2009
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
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.


-- 
Apr 02 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
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.
Apr 02 2009
parent dsimcha <dsimcha yahoo.com> writes:
== 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.

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.
Apr 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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 ?


-- 
May 04 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2757





------- Comment #4 from maxmo pochta.ru  2009-05-05 06:09 -------
Because your solution doesn't solve even your problem.


-- 
May 05 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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. --
May 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


-- 
May 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Aug 23 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2757





--- Comment #8 from nick barbalich <nick.barbalich gmail.com>  2009-08-25
03:57:45 PDT ---
(In reply to comment #7)
 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.

Bartosz - Thanks for the reply. I found this reference to "postblit": http://www.puremagic.com/~braddr/phobos-trunk/2.0/struct.html#StructPostblit But I use the Tango library. Will an example be available in Tango, or will there be an equivalent available for Tango ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 25 2009