Dirk Reiners wrote: > Hi Allen, > > Allen Bierbaum wrote: >>> To go between threads you would have to use a MTRefPtr. That one behaves >>> pretty much like the current FCs: whenever it is dereferenced it returns >>> a CPtr for the current thread's aspect. >> These last couple points seem pretty nasty to me. Just to be clear, >> this means that I can't use RefPtr's like I do today. For example I >> can't just store a RefPtr as a member of an application object and then >> have that object call the opensg object from whatever thread it happens >> to be executing within? > > No, for that you'd have to use an MTRefPtr. > >> This seems like a pretty severe limitation to me. I would think we >> would want the recommended user handle (RefPtr) to "just work" in all cases. > > There is overhead for that, and not many applications use it, and even > if probably not for all RefPtrs. If you want to do it you can use > MTRefPtrs everywhere and effectively get the current behavior.
This still worries me. What amount of overhead does it introduce? Are we talking a table lookup and indirection or is it something heavier than this? I could see this being too much overhead for the internals of OpenSG, but at the user level it seems to me that this would be fine 95% of the time and then users that know they have an issue could just get a reference to the cptr from the MTRefPtr (much like they would even with RefPtr's) and use that for the performance critical parts of their code. As far as most applications not using it, I agree. But I see that as a problem to be fixed. Please take this as constructive criticism, but IMHO, the fact that there are not many good multi-threaded examples and that there is not an easy way to enable APPCULL_DRAW style separation right now is why not many apps use them. This a bit of a pity since one of the largest selling points of OpenSG is that it has such nice support for multi-threading but yet as you say "not many applications use it". I would personally like to see that change now that we are all in a multi-core world where OpenSG could really shine. Back to MTRefPtr's though... Are there default constructors to convert from RefPtr to MTRefPtr? For example could I just use an MTRefPtr in my application everywhere that I would use a RefPtr (including CoredNodePtr's)? >> Don't RefPtr's currently work in any aspect they are used. IIRC they >> are and changing this would break most all of our applications. > > Just like FCPtrs, yes, but that's the main part that's changing. > >> I am using those, but I think they can be ported over very easy once the >> recommended user handle type is selected (RefPtr or whatever). > > I think so. > > Yours > > Dirk > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Opensg-core mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-core > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
