Hi, On Sat, 2009-06-13 at 12:12 -0500, Carsten Neumann wrote: > Hi Gerrit, > > Gerrit Voß wrote: > > On Sat, 2009-06-13 at 00:37 -0500, Carsten Neumann wrote: > >> attached is a patch that implements that. With it applied I get: > > > > no patch attached ? > > argh! sorry about that, this time its there. > > >>> In general this means if an object is created with createLocal(), it > >>> must not point to something created with create(). > >> well, actually it is the other way around, the parent pointer from Image > >> to TextureObjChunk is causing the problem, because it gets synced over, > >> but in the destination aspect the TexObjChunk does not exist (since it > >> was createLocal() ). > >> > > > > hmm, I don't see a direct sync problem but I do see the following > > general problems: > > 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. > - 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. > > - image::change does not check if the parent ptr is NULL. This > > happens because the weak ptr returns NULL as the createThreads > > object goes out of scope. > > I don't see why Image::changed has to check the parent pointer (they are > not weak pointers, they are uncounted, thus they can not suddenly become > NULL the way weak pointers can), because if the parent goes out of scope > it should remove itself from being a parent to the image. That does not > seem to happen, is that the real bug here? ah, ok we did not change this. So than the old thing happens that NULL is synced. > > - there is a chance for a race condition when image calls > > parent->changed and the createThread has the parent run resolveLinks. > > But in this case this should not be a problem as parent::changed and > > parent::resolveLinks are disjunct. But it is something to think > > about. > > are you saying that the renderThread Image has a parent pointer to the > create thread TexObjChunk? Uhm, is there any code in the system that is > prepared to deal with pointers from one aspect copy into another? no, my assumption with the weak ptr was wrong so this conclusion was wrong to ;). > > - 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. So my take is that this allows to violate our 'no NULL ptr in field' assumptions and that this is the thing that should be fixed. I'm currently looking into this. 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
