[osg-users] SingleThreaded leading to whole application just running on one core

Robert Osfield robert.osfield at gmail.com
Mon Sep 26 08:38:19 PDT 2016

HI Christian,

On 26 September 2016 at 15:49, Christoph Weiss <weiss at wsoptics.de> wrote:
> Robert, I'm not quite sure what prompts you to bring in personal attributes
> here.  Nor do I see any hyperbole to begin with.  I stated that I strongly
> disagree.  You can in turn disagree.  I never was my intention to make this
> personal, and quite frankly I do not see how I should have.

When it comes to perspectives of what is right or wrong for the OSG it
absolutely has everything to do with my experience.  I more than
anyone else in the community I witness how the OSG gets used across
the broad spectrum of users.  There is no one else who provides more
support to users, fix more bug, work with users and clients across
many professional domains and usage cases.

When I say something is a "very specific usage case" then it's based
on this experience. You then said "you strongly disagree" with this,
then I leaves me wondering how you can speak from greater authority on
how the OSG users use the OSG.

What you can say is that you know your usage model for your
application more than I.  I could understand how this to you is the
most important thing from your perspective, this is exactly what I
expect of OSG users and is positive thing.  However, where I feel
you've overstepped the make is making broad statements that your usage
case is the general case from the OSG perspective.

It's my job as project lead to look at all the usage cases and issues
that the OSG users have and guide the OSG in the right direction, I
take not of usage cases like your own, but it's just part of wider
project.  Just in the same way I also need to know the wider context
of where the OSG sits, it's not something that is static, it evolves
over time.  An import thing for a project lead is that you do take to
whimns and move the rudder of the ship left then right randomly in
response to the latest greatest opinion.


Repeatedly in this thread people like yourself have strongly asserted
how wrong the OSG is doing things.

As spent the time investigating the issue I've found that it's
actually that this standpoint has been based entirely on the
assumptions made by those having problems.

The assumption that the thread affinity will not be set, and for some
it seems it should never be set, is building your house on sand.  If
you are writing a multi-threaded application one should be aware of
and make conscious decisions about thread affinity.

The OSG and OpenThtreads don't make assumptions that thread affinity
will be correct in it's default, inherited state, it where appropriate
explicitly sets the affinity.  It may not do a perfect job in this,
but it does at least try to do what it can.

>From what I have learnt this is is far more an education issue rather
than a technical one.  Partly is educating about what the OSG does and
why it does it, but it's also more general than this - the assumptions
about thread affinity being made in end users applications is clearly
insufficient.  This lack of education of this later issue is far
bigger than the OSG project.  Sadly the lack of education on threading
issues is not helped by the lack of affinity functionality of C++11
threading as an issue ignored is not one that is solved.


More information about the osg-users mailing list