HI Fabien, On 25 September 2016 at 22:52, Fabian Wiesel <fabian.wie...@gmail.com> wrote: > Yes, both cause the threads being distributed across the cores. That is > probably also why initialising TBB early in main helps, as it creates a pool > of worker threads. For my app, you can consider it solved. > But don't you see a difficulty for OSG, if you cannot use any threading > library without additonal setup code?
The only "difficulty" is when using a certain usage model when threading, it's not a general issue. The issue looks to be isolated to the case where users set up threads after the viewer has been realized. I do agree that the inheritance of the affinity to child processes is not ideal. It's not something that I was aware of when adding the processor affinity to osgViewer. It would good to find a way to prevent this implicit inheritance when not desired. Setting the processor affinity is an important part of making a real-time visualization application run at a solid 60Hz, having thread jump from core to core breaks cache and can break frame, it's why the code exists in osgViewer and why it doesn't make sense to just remove it. Being able to provide user control over affinity is something I've had in mind for a number of years, with the decoupled way many of the OSG threads are set up there isn't an easy 1:1 mapping that the users can get there hands dirty with to set things i.e. the user doesn't manually create the threads, the viewer, the databases, the video plugins all create threads depending upon how they are configured and whether they are required when certain types of data is loaded or not. These threads that are created are assigned when possible to sensible locations, but it's not idea. If there was an easy and intuitive route to user control of thread affinity it would have been implemented already. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org