Hi Robert,
When running SingleThread the OSG just sets the affinity of the
current thread. That's it, that's all it's doing.
This actually has a very bad side effect that I only noticed now. Since
it explicitly sets the affinity to core zero, any other application that
does so will share its CPU entirely with it. In particular if you start
a SingleThread OSG application twice, it will share the core and have
degraded performance.
I also wouldn't be surprised if the kernel favors core zero for things
that aren't properly multithreaded, but I'm just guessing here, and
maybe that's a thing of the past already, at least under linux.
I'm not even sure why setting the CPU affinity to a single core should
improve performance at all unless the OS's scheduler performs poorly.
It does not explicitly change the affinity of any of threads created
by user applications. I think what Pete found was under Linux is that
threads created after the set affinity to the current thread, all
threads created by that thread then inherit that affinity, which what
his code snippet looks to work around.
Yes, they inherit the mask. It would be quite similar if OSG set up a
ulimit().
Judging by your comment, this has already been discussed and not deemed a
fault that should be fixed?
Changing something that was done by design because one class of usage
on one platform doesn't do exactly what they want. There isn't a bug
to fix here. It's sub-optimal behavior for certain types of
application usage on certain platforms.
I agree, it's not a bug, it's a design choice. However, it's a rather
strict enforcement on the user.
I haven't yet seen a reason to change the behaviour, it's not the case
that the behaviour is wrong for all users, it's not a bug. Removing
the setting of affinity would leave the main thread to float around
and increase the changes of breaking cache. The OSG is just trying to
do something sensible out of the box for most users.
I totally understand that. But I disagree with it being the most
sensible choice ;) Subclassing CompositeViewer is a good solution. For
me, it really does not make that much of a difference if the design is
changed or not. I'd be surprised if I was the last to run into this
issue though and spend quite some time on figuring this out.
Apart from this, I think in general a library should not impose
restrictions on the calling thread without it explicitly asking for
them. Suppose a library just decided to close file descriptors 0, 1, 2
because it doesn't need them and can thus save some memory...
In the case of Qt application, they should be run multi-theaded, for
all the native windowing systems the OSG support all work
multi-threaded without any problem. Unfortunately Qt has created a
series of problems on the threading front that we've had to try and
work around, Qt then goes and moves the goal posts though between
releases. it's been a real pain to try and keep osgQt working well
over the years. If you don't need a traditional 2D UI then it's
generally best to avoid Qt as it causes problems because it has it's
way of working that doesn't fit well with the needs of real-time
visualization.
Alas, we're quite stuck with Qt since we require a 2D UI. But thanks
for the information.
Christoph
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
