On Thu, Mar 12, 2009 at 10:27 AM, Carsten Neumann <[email protected]> wrote: > Hello Allen, > > Allen Bierbaum wrote: >> On Thu, Mar 12, 2009 at 9:40 AM, Carsten Neumann >> <[email protected]> wrote: >>> Allen Bierbaum wrote: >>>> It sounds like RecPtr holds a referenced counted pointer, but that it >>>> only works in a single aspect and that to use a pointer that can be >>>> used in multiple aspects you would have to use MTRecPtr. Is that >>>> correct? >>> yes, except for MTRecPtr none of the pointer types work across multiple >>> aspects. >> >> This may be a dumb question, but how does RecPtr work at all then? >> How does it detect the correct aspect to allocate the object in and >> the correct aspect to look up the data (FC fields) from if it doesn't >> know about the aspect? > > it contains a pointer directly to that aspects copy of the container. > >> More specifically, let's assume that I did use a RecPtr in DB below to >> create an object: > > sorry for splitting hairs here, but you don't use a RecPtr to create an > object, you use the ::create static member function of the type, which > looks up the current aspect (a thread local value) and records the > generated object as this aspects copy. The other aspect copies don't > even exist at this point (that is different from 1.x), they only come > into existence when you sync to the relevant aspect.
Gotcha. So this is the key, there is something somewhere that is looking up the aspect and effectively creating a MTRecPtr (or easily could) which is then be converted over to a RecPtr which in the process looses the thread safety part. That makes more sense. >> - How does OpenSG know to create it in the DB aspect (ie. add to that >> change list and put copy in that aspect)? > > during creation of the object it looks up the aspect associated with the > current thread. > >> - When Main sync's the changes from the DB changelist, how would I get >> access to the node from main? (do I have to traverse the scene graph >> to find it somehow > > yes that would be one way, or you could pass a MTRecPtr from DB to Main. > How do you do it currently? I just use RefPtr everywhere and don't worry about memory at all. :) > and if so, how does RecPtr know to look only in >> that aspect) > > all the pointers inside an aspect's copy of a container point to copies > of containers inside the same aspect. By only following pointers (in the > fields, not the one to the AspectStore of course) you can not fall out > of the current aspect. Ok. That makes sense. >>>> For example if I had code with the following threads: >>>> >>>> - Main: Traversal, rendering >>>> - DB: Load items in the background, sync into main thread periodically >>>> - Work: Background thread to do work on nodes that came from the main >>>> thread >>>> >>>> Then would I need to use MTRecPtr? >>> only if you pass around pointers across aspects. I can see that is quite >>> likely the case between Main and Work, e.g. if Work has a queue in which >>> you put (from Main) pointers to nodes that need to be processed, that >>> should be a queue of NodeMTRecPtr. >>> And for Main and DB: if you pass a pointer from Main to DB to indicate >>> where to add loaded stuff that should be a MTRecPtr. For most (all?) >>> other pointers I don't see where they cross an aspect boundary so you do >>> not need the MTRecPtr, just RecPtr is fine. >> >> So, if I take a node in Main and subChild a subtree, all of the nodes >> under that node will be removed correctly even though the RecPtrs >> creating them were created in another aspect, correct? > > yes. > > (I think it >> should, just very confused about these pointer types and their >> interaction with threads and aspects) >> >>>> By the same token, what ptr corresponds to the old RefPtr? (it looks >>>> like it would be MTRecPtr) >>> yes. >> >> Why the need for the RecPtr type at all then? Seems like raw pointers >> get all the performance improvements needed for the core. Maybe I am >> missing something big here. > > MTRecPtr needs to do a thread local storage lookup (to get the current > aspect id) then get the AspectStore for the pointed-to container, use > the aspect id to index into a std::vector<FieldContainer *> to get the > current aspects copy every time is dereferenced. > RecPtr in contrast returns the internally stored pointer. So RecPtr is only needed so we can have higher performance smart pointers that are safe only within one thread. That makes sense. >> Thanks. Sorry for all the questions, just very confused. > > Confused about why we have all the pointer types, or confused about when > to use which one? If the latter can you give examples where you are not > sure what the right choice would be ? A bit of both. It sounds like from a user perspective MTRecPtrs are the way to go because you can use them and forget about memory issues. Internally to OpenSG things get more complex because of performance optimizations with RecPtr being the higher performance reference counted ptr, UnrecPtr being a very strange one that still reference counts, TransitPtr being there to prevent bugs in code, and Cptr for the really high performance stuff. My head hurts, but I think I understand. :) -Allen ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
