Hi,
> As far as I understand, you aren't mixing in OSG code with another
> library with a different license, you are just linking to both so the
> licenses shouldn't conflict with each other - as long as you honour
> the individual licenses with how you use them in your applications.
Yes, my
Hi,
Currently, I am checking the possibilities to update my company's proprietary
application from using OSG 3.0.1 to use a newer version. On GitHub, I could see
that with OSG 3.4 the license document changed from OSGPLv0.0 to OSGPLv1.0.
There are only minor differences and I understand that
inspection and interest, I attached my modified version of
Notify.cpp which has a preprocessor flag OSG_NOTIFY_STREAM_PER_THREAD
to toggle the use of thread local storage.
Cheers,
Matthias Schütze, Germany
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library
submit it, now?
Cheers,
Matthias Schütze, Germany
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
by the race
condition by default. So, I would like to know, if this drawback is
commonly accepted in order to prefer OSG efficiency over guaranteed
thread-safeness?
I look forward to your feedback!
Matthias Schütze, Germany
___
osg-users mailing list
osg-users
to me, why there is no
locking mechanism or the like to make the stream thread-safe?
I appreciate every enlightenment or correction!
Matthias Schütze, Germany
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org
::NotifyHandler subclass. This way, the
notify handler would be responsible for thread-safeness again (as it
is now).
Cheers,
Matthias Schütze, Germany
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org
7 matches
Mail list logo
