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. > 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. 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? 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
