Destruction in D

bitwise via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sat May 2 14:13:22 PDT 2015


On Fri, 01 May 2015 14:37:40 -0400, Idan Arye <GenericNPC at gmail.com> wrote:
> Structs allow you to implement ref-counting smart pointers like you can  
> do in C++. There is an implementation in the standard library:  
> http://dlang.org/phobos/std_typecons.html#.RefCounted

Yeah, I guess I should have taken the existence of RefCounted as  
confirmation that D has deterministic destruction for structs, but the GC  
reference makes some pretty broad generalizations that do not seem to be  
entirely true.

> But for something as structured and as heavy as gaming resources, I  
> would go for a more manual approach like a repository-style  
> architecture, where you manually tell the repository to load/release the  
> the resources.

A quick googling of "repository style architecture" yielded a large  
variety of pages, including a 143 slide presentation, which I have no  
intention of reading =/ I think such an architecture would be overkill for  
something like this.

In any case, manually loading/releasing assets is a huge step backward.



On Sat, 02 May 2015 09:22:57 -0400, Márcio Martins <MARCIOAPM at gmail.com>  
wrote:
> A very easy and simple solution is to have a queue of unused
> textures in your asset manager, that any thread can push to, but
> only one thread consumes from. Whenever the last ref is released
> you push a texture into this queue, and at the end of each frame,
> while the GPU is busy rendering or flipping, you go through this
> queue on the appropriate thread and delete the textures.
> This has the advantage of making your timings deterministic, i.e.
> a function won't suddently take 200x longer because it happened
> to release the last ref to a texture.

This sounds like it could work.

> Also, remember that aquiring/releasing refs in a threaded
> environment is quite expensive, and you don't want to be doing
> this while passing a texture around in your graphics pipeline, so
> you probably shouldn't be counting texture refs at the texture
> level, but maybe when you load/destroy a material, for example.

True. I was going to pass the RefCounted assets by (ref const), but the  
annoyance that brings hardly seems worth it at this point.

I think I would wrap the assets in a class instead though, and let the  
destructor decrement a ref count in the asset manager instead of pushing  
it to a queue. That way, it would be at the discretion of the asset  
manager to destroy the assets as needed. At first, I would most likely  
destroy the assets immediately, but eventually, the destruction could be  
delayed until memory runs thin to cover awesome code like this:

while(true) {
     Texture tex = Asset.GetTexture("card");
     drawQuad(tex);
}


More information about the Digitalmars-d-learn mailing list