Marcus Lindblom wrote: > Allen Bierbaum wrote: >> Marcus Lindblom wrote: >>> Allen Bierbaum wrote: >>>> As far as getting pyopensg to work on head, I think the big change is >>>> going to be modifying the code I added for dealing with RefPtr's and >>>> FCPtrs and making that code use the new ptr type that Dirk and Carsten >>>> are working on. If that ptr type can not be used across aspects, then >>>> we may have to do a bit more tweeking to try to make things work. >>> I hope nobody minds me ventilating some thoughts here. ;) >>> >>> AFAIU, the point of the refactoring is to make things simpler for the >>> user by using raw c-pointers in most places, and speed things up by not >>> copying fcptr's and calling GetAspect() on every dereference. (Since >>> most function calls occur within one thread and thus one aspect, this >>> seems fine). >>> >>> Either there will a new kind of smart (auto-aspect) pointer (MTRefPtr?), >>> or just a function called mapPointerToAspect() that does the same thing >>> procedurally. >>> >>> I think it's pretty nice, since multithreading shouldn't be more >>> automatic than necessary (you need to know what you're doing anyway) and >>> from my limited perspective, it seems to map cleanly to a python >>> wrapping too? >>> >>> Making wrappers for raw c-pointers is simpler than with custom pointer >>> types, no? And using RefPtr's in the python objects ought to work too? >> The wrappers would be on the RefPtr type and it should be easier since >> we will hopefully just have one unified type instead of having RefPtr >> --> FCPtr --> Cptr. > > >> As far as easier, my concern above is that I want to make sure python >> users can rely upon the pointer "just working" no matter what thread or >> aspect they are in. > > Right. Then you should be able to use the MTRefPtr Dirk mentioned > before. However, IIUC the default type for all functions in C++ OpenSG > will be a raw pointer (or reference), so you'd need to dereference there.
Agreed. It just means that all the conversion routines will have to work from/to whatever type the user-level APIs expose. > >> Unfortunately it sounds like we may be in the minority as far as OpenSG >> users that are making use of multiple threads and aspects though. :( > > Well, it hasn't been working well in 1.x. There was issues with > copy-on-write, ref counting and a few other things that have made me a > bit wary. I'd love to use it, and we chose OpenSG because we know we'll > need it sooner or later. (Sooner is getting nearer..) > > I hope to be able to start fresh with 2.0 and try to fill up all the > "OpenSG thread holes" in my app (or OpenSG) one at a time then. I highly suggest it. IMHO, clustering and threading are *the* reason to use OpenSG. The abstractions the system have for these things just make things work well. > Anyway, if I would use multiple threads/aspects now, I would probably > move pointers between thread very little, and when I did so, I would > have to take care. So having to map a pointer between aspects would not > be a big problem. But it depends on how one's application is structured. > > Do you do a lot of inter-thread communication with PyOpenSG? We call quite a bit of C++ code that does things for us in other threads. For example the background loader code we added to OpenSG 2.0. This is an area we want to expand on in the future. If/when we can start using boost::function's as callbacks that work with python callbacks, I think we will be making even more extensive use of threads with OpenSG and python. -Allne > > Cheers > /Marcus > > ------------------------------------------------------------------------- > 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-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------- 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
