Hi All,
Carsten Neumann wrote:
>> But, what happens if:
>>
>> - I have a primordial rendering thread and 2 background threads (P,
>> B1, B2) (each with their own default OpenSG settings)
>> - I create an object in P, store it with an MTRecPtr p_node, and share
>> that Ptr with B1 and B2
>
> you need to sync the aspect of P with those of B1 and B2 before you can
> access the object from either thread.
> BTW this has not really changed from 1.x, except that in 1 the copies of
> P where already existing in the B1/B2 aspects, however they did *not*
> contain the correct values before the sync.
Yup. The equivalent is accessing an uninitialized pointer: there is nothing to
point at, so the result is undefined.
>> - When B1 or B2 accesses it, what data do they see? (assuming no
>> manually changelist syncing)
>
> if there has been no sync from the aspect of P to those of B1/B2 your
> application is likely to crash. The object you are trying to access does
> not exist before the sync.
We could theoretically create a dummy object, but it would just mask what
amounts to a program error. It would be nicer not to crash but print an error
message or raise a signal (which is practically the same as a crash, but more
controlled) or throw an exception.
>> - What happens if in B1 I add a new node (b1_child) as a child of p_node?
>
> b1_child only exists in the aspect of B1 until you sync from aspect of
> B1 to aspect of P and aspect of B2.
... and you can't do that until you sync p_node into the aspect.
>> Now option 2, what happens if I do this instead:
>>
>> - Same as above, but I explicitly set the aspect id for all threads to
>> be the same as the primordial thread
>
> you have three threads operate on the same aspect so becomes your own
> responsibility to coordinate their actions.
Yup.
That hints at a fundamental limitation of the OpenSG multi-threading model: it
only operates on a whole field basis. If you change the same field in multiple
aspects, the last one to sync wins.
Which in general makes a lot of sense. For the children field we could think
about a different behavior, but I'm very weary about adding special cases for
specific fields. Maybe we could hide it in a special Group (MTCollectorGroup)
that does something magic. Not sure what, honestly, not sure how to handle an
object that is added in one thread and at the same time removed from another
thread.
Stuff to think about...
Yours
Dirk
------------------------------------------------------------------------------
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
