Hi,
On Sat, 2009-06-13 at 21:53 -0500, Carsten Neumann wrote:
> Hi Gerrit,
>
> Gerrit Voß wrote:
> > On Sat, 2009-06-13 at 12:12 -0500, Carsten Neumann wrote:
> >> hm, now I'm wondering if perhaps I was misunderstanding what
> >> createLocal() does. Can you explain please? Specifically:
> >> - if I createLocal an object in aspect N and sync to aspect M, will
> >> there be an aspect copy of the object in M, i.e. can there be a
> >> meaningful pointer to the object in aspect M ?
> >
> > not really unless you are willing to accept global objects which are
> > the same for all aspects, require different access protection and
> > take care that their pointers don't jump aspects.
>
> ugh, does not sound pleasant to me... ;)
not quite, it might be of some use sometime though ;), but I would say
before that some pieces are missing.
> >> - what is the intended use, i.e. what things should be created with
> >> createLocal() and what does that buy us?
> >
> > One major reason was to build application objects with OpenSG. So inside
> > OpenSG itself they aren't of much use. E.g. their main occurrence is in
> > ComplexSceneManager.
>
> ok, so we probably need to get rid of a bunch of uses in the system, the
> patch I sent with the last mail did that for the internal chunks of
> Simple{,Textured}Material and the State object in PrimaryMaterial. I
> remember a bunch of uses of createLocal() in the Stages, that I need to
> think about whether they are safe.
No I would not like to get rid of them. Inside the stages for render
local objects they should be perfectly fine, that actually was the
second major use I forgot about ;). And having them is a good
testcase to find these kind of bugs ;)
> phew, cross aspect pointer sound scary to me ;)
not really, actually we have them inside OpenSG. The ptrs stored
inside the window::globjects actually are cross aspect, but not
in fields, that makes them easier ;).
> >>> - If the createThread manages to change the image::parent field
> >>> again after the sync the parent link in the rendering thread is
> >>> lost. That is not really nice and has cropped up here and there
> >>> (most famously in window) and something that needs a general
> >>> solution.
> >> hm, I may be missing something here and in that case I'm happy to change
> >> my opinion on this, but from what I understand the rules for using
> >> createLocal() are:
> >> - an pointer to a createLocal() object may only be stored in a field of
> >> an object that itself is createLocal().
> >> - any pointer stored in a field of a createLocal() object must point to
> >> a createLocal() object (this can be relaxed to only apply to children
> >> fields).
> >>
> >> The latter is violated in SimpleTexturedMaterial as it puts the Image
> >> pointer in to the createLocal() TexObjChunk.
> >
> > I don't see either a problem. The problem was that the image parent
> > pointer field contained a NULL pointer. Or more general that the
> > pointer to a createLocal object is not synced, so it is NULL in
> > the target aspect.
>
> ok, I think here is the core of the problem: you prefer much more
> relaxed rules for where one may use createLocal() objects compared to
> what I've outlined above. Do you propose any restrictions on them or do
> you think it should be possible to use them essentially everywhere?
If possible I would like to use them where ever it makes sense. Actually
in this particular example I would prefer to get rid of the dependent
objects inside SimpleTexturedMaterial in the createThread as they aren't
of any use in there.
I don't have a good heuristics where they make sense, though their
usage for render local data is a good example.
> Wouldn't that imply every iteration over a pointer field would have to
> be ready to deal with intermittent NULL entries?
no, at least as long as there aren't any bugs inside OpenSG ;). We
already have the notion of which ptr mfield does allow NULL ptrs
inside and which does not. All I would do is close the backdoor
so NULL ptrs can't sneak in via the sync mechanism. That's what
I'm looking at. For parent fields it is easy for general fields
it is a little more work.
> Does it make sense to add this (easy to forget) requirement for
> something that you said above "inside OpenSG itself they aren't of much
> use" ? -
well I forgot the render local usage, so they are of good use even
inside OpenSG ;)
> These are not rhetoric questions, I'm curious how you see it
> and what the tradeoffs are/
I currently see no particular tradeoffs that are specific to these
objects. If they highlight general problems I'm more for solving
the general problems ;)
kind regards,
gerrit
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
