Hi,
Wow, before this escalates: OSG is setting the affinity for some of its
own threads, which is totally legitimate.And I totally agree, that it
would be nice to have an interface to control the core/wether affinity
is used in single-threaded mode except from having to subclass the viewer.
If all other threads are forced to one core (as reported), by setting
the affinity of the osg-threads, it is clearly a bug and needs further
inspection . I've been working with OSG in a multi-threading environment
for several years and didn't experience problems so far however.
So creating a minimal example might help to find the problem, if there
is one.
Cheers
Sebastian
Affinity is set by default because the it will provide the best
performance for majority of OSG applications. This might be a
"terrible" reason for you, but the OSG development is motivated not by
just focusing on one class of users needs or preferences, default
settings we try to do the best for most OSG applications.
I have no particular desire to repeat the last discussion, but i'll say it
again.
Hardcoding CPU affinity is:
a) unexpected
b) a premature optimisation
c) not consistent across platforms
d) not easily reversible
e) a performance killer outside of one specific application model.
f) conflicting with other libraries that expect to set CPU affinity linked in
the application
It is a terrible idea, and doing it in the context of a library is just plain
wrong.
PS. Reason f) doesn't really exist because other libraries don't do this, for
reasons a,b,c,d and e.
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68716#68716
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
