<Xordan> thebolt: You said a few days ago that selfdestruct doesn't kill the object. What does it do exactly then?
<thebolt> Xordan: nothing but reaching ref=0 kills an object
<thebolt> selfdestruct removes the object from all internal lists it knows about
<Xordan> hmm. So let's say I have two regions loaded, and both regions own (or own something that owns) a material. One of the regions is unloaded and selfdestruct is called on this material. The material wouldn't be freed because it's refcount is above 0, but it would be removed from all internal lists.. but region 2 (or whatever inside it) might still assume (and should be able to?) that the material is still in those lists yes?
<thebolt> Xordan: well, "internal lists" for a material means the materiallist
<thebolt> Xordan: so it will be removed from materiallist
<thebolt> Xordan: however, it will still be referenced as a child of region2
<thebolt> and meshes in region 2 that use it will still reference it and keep it alive
<Xordan> Okay. So let's say we've unloaded region 1 and are in region 2. Then we go back into region 1 and it attempts to load the material (or return it because we check for duplicates). What happens?
<Xordan> Check duplicates would return false and it'd load another instance of the material right?
<thebolt> yes
<Xordan> That isn't really a desirable effect.. hmm
<thebolt> well, thats how regions work atm
<thebolt> and it sucks
<Xordan> yes
<thebolt> i would ideally see a system where things such as textures & materials are in the engine list as long as there is any reference to them.. that woudl however require that you always use a region to hold the references to stuff..
<Xordan> I can think of a few ways to improve this.. but I'm not sure if they're just ignoring the main problem (which is how regions work).
<Xordan> Well
<Xordan> We could move the handling of all unloading (as in, selfdestruct on objects which would be owned by regions) to the engine to start with. So all the region does is ask the engine to try and unload, and not try and do it itself.
<thebolt> i think that is wrong place to start.. right place is to identify who should own references to stuff and when should those references be released..v <Xordan> I don't like that a region explicity tries to delete certain objects. It should be up to the engine to 'decide' whether or not something can be deleted, if asked to make that decision by the user.
<Xordan> Yes, maybe that is better
<thebolt> might be that some engine-objects actually should have dual refcounters
<thebolt> one scf refcount and one "engine internal" refcount
<Xordan> Yes, that's an idea.
<thebolt> the scf refcount works as normally, deletes object on ref=0 etc etc.. engine refcount counts how many places internally engine holds refs.. stuff like regions for example
<thebolt> when engine refcount goes to 0 object is removed from materiallist/texturelist and scf refcount lowered by 1
<thebolt> (or each engine refcount implies one scf refcount.. doesn't matter really)
<Xordan> probably nicer to have the single count for all of engine, as they should be released at the same time.
<thebolt> yea, but then you have to handle them differently internally, and technically it doesn't matter if scf refcount is also increased
<thebolt> so materiallist would by default own one "engine ref", and region one each
<thebolt> on normal region destruction only the region destruction one is removed
<thebolt> but then there is the "remove as many engine refs as possible" method (ie deleteall) that removes the regions and the materiallists engine ref (if there is any).. however as long as any region keeps an engine-ref it stays in materiallist & scf count sin't reduced..
<thebolt> hm, still gives other problems with reloads etc :/
<thebolt> Xordan: maybe look around how other open source engines handles it?
<Xordan> Well, do it slightly different. Have a refcount for lists and the engine itself, then one for everything else. So a 'storage' refcount as a 'using' refcount. When the 'using' reaches 0 then we can remove it from all the lists and from engine. Then the object is removed.
<Xordan> *and a
<Xordan> As that's what we really want to know, if anything is actually using that object. If not then there's no reason to keep it around
<Xordan> At least, I don't see the materiallist and engine as being 'users' like a meshobj is
<thebolt> well, then the "use" refcount be the scf refcount actually
<thebolt> is doable via custom SCF implementation for those classes i guess (in same way as the pooled ones)
<thebolt> Xordan: however, consider the case when you load just a material or its just created
<thebolt> then it is just in the engine list, nowhere else
<thebolt> and it shouldn't be removed
<Xordan> Ah, but when you load just a material, you assign it to a region
<thebolt> you don't always use regions
<Xordan> At least, that's what seems to happen
<thebolt> it is fulyl valid not to have any region
<Xordan> hmm, yeah
<Xordan> damn those regionless people making life difficult[[BR]] <Xordan> In that case.. I'm not really too sure. We'd need some other way to mark that the object is being 'used'
<Xordan> Even if it really isn't
<Xordan> (yet)
<Xordan> Maybe keep another list for that purpose, everything of a certain class which isn't added to a region is added to that list, then it's up to the user to decide when to remove the object (by removing it from the list).
<thebolt> i was just thinking something like that.. have an "engine ref" that is transferred to the region when object is first added to region
<thebolt> so if object isn't in any region then the materiallist owns that ref
<thebolt> but once it is added to any region they take over that ref..
<Xordan> Yes