Hi Christoph, On 26 September 2016 at 11:01, Christoph Weiss <[email protected]> wrote: > This sounds a bit as if this was a rare thing to do, or at least a design > choice that can or should be avoided. I think on the contrary, explicit > thread handling is something that is slowly going to die for many > applications, the future lies in futures (pun pun) and parallel version of > standard algorithms. C++17 adds a lot of parallel functionality that the > user can use without caring about threads themselves. The code sample that > I posted yesterday is a typical std::future application.
I think you need to trust me on the scene graph performance front. Thread affinity is important for performance. Future threaded support in languages makes no difference to the cost of threads moving from core to core. It's the same problem no matter what API you wrap it up with. >> If there was an easy and intuitive route to user control of thread >> affinity it would have been implemented already. > > > What would be wrong with an osg::setThreadAffinity(...) function a user who > knows what they're doing can use? The OSG users don't always know what threads are active, let alone what ones they need to set to get best performance. The OSG in it's defaults try to do the best it can for users. It's not perfect, but it at least tries. Robert _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
