From: Gerrit V. <vo...@ca...> - 2007-04-01 15:39:42
|
Hi, short one, I'll try to find more time for more details the next days. Looks like I'm not going to be cut off for to long ;-) On Sat, 2007-03-31 at 16:31 -0500, Dirk Reiners wrote: > Hi Gerrit, hi Allen, > > Gerrit Voss wrote: > > > > hmm, I don't think it would be a good idea to push my tree and than run > > away, so I guess I have to bite the bullet and redo it after your > > changes. Anyway I wanted to clean it up for a long time so it might be > > a good opportunity ;-) > > OK. I hope it won't be too much of a bullet. I hope not, but there is nothing much we can do ;-) > > And I just hacked fcd2code to deal with mixins ;-). But as I even got > > you confused (the FC is actually derived from RC) it seem to be time for > > a change ;-) > > I think I just mixed up RC and FB. But yes, it is confusing. :) ;-) > > my current feeling is that we should keep the refcounter inside the > > container and don't push it to a central location. Having anything in a > > central location is what caused most of the trouble. > > > > As the aspect copies are now independent and only linked via the aspect > > store we actually should be able to handle containers locally as we can > > destroy a single copy independent of the other copies. > > Hm, so you would only keep aspect-specific refcnts? And would you > actually delete the local copies when their refcnt goes to 0, and remove > them from the AspectStore? The AspectStore would then be deleted when > all aspects are removed. yes this is the way it should work. I don't know how much I finished when I did the initial CPtr code because I was more interested in getting the general sync working. But the current implementation should at least partially work this way. I'll try to do some quick tests on the cleaned version. Anyway you could just ignore it for now while playing with the ref pointers. > I guess the CL sync would keep all the refcnts consistent. We just need > to be able to handle situations where you sync into an aspect where the > FC has been deleted already. that should be ok. > And if we can handle that, we can handle > many other things that might be interesting: having FCs only in some > aspect (only create them when they're synced into an aspect) and have > different numbers of aspects for different FCs. that is how it is done right now. The aspect copy is created on the first write. > > > How is refcnt really handled right now? I know there is stuff in RC, but > there is also the magic MemObject in Base. MemObject is just for other small things that need ref counting, like the threading classes, the changelist, ... I would probably switch that in a second step if needed but it has nothing to do with the container ref counting. > > yes you can not do without them. Well you can but than you have to have > > a ping pong sync between aspects to get everything destroyed properly. > > See above. > > > As > 95% is cleanup I don't see anything really evil ;-)) > > Well, there is cleanup and there is CLEANUP. This one is the latter... > ;) It will change a very large part of the code. Yeah but the principal sequence of calls should stay the same. > > I'll think about it a little bit and if I find something before being > > cut off I'll let you know. > > OK. > > > On a more technical note, would it make sense that I quickly collapse > > all the mixins as I wrote them it might be quicker and give you a > > cleaner picture to start from ?. > > > > I should be able to spend the few hours it should take. > > Whatever you can do to make my life easier would be welcome. ;) ok, I've started to throw out some of the mixins so that you have a clearer picture of what is happening. gerrit |