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.
> - 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?
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.
>
>>> 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.
> 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 ?
Cheers,
Carsten
------------------------------------------------------------------------------
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
