One of many similar examples can be found here.
src/osg/Drawable.cpp:783
You suggested that using a singleton pattern may solve this issue and
I agree it
could because the buffer wouldn't be allocated / updated until the
first access; however,
there may be some performance considerations such as:
- Extra check for NULL before every access (or init case)
- Extra function call on the stack
- You still have a race condition if the first access could come from
multiple threads which
would put a mutex in the way
At the very least you would have to centralize the many (20+?) static
objects so that you could
control with one call when they all get initialized.
What are the downsides to the patch I submitted (submissions list)
with a DisplaySettingsListener object that solves this
problem and expands functionality across all platforms by supporting
dynamic changes to the max number of contexts?
Total cost is 1 extra pointer, plus some init & cleanup overhead.
Dan
On Jul 25, 2006, at 6:44 PM, [EMAIL PROTECTED] wrote:
On Tue, 2006-07-25 at 15:23 -0400, Daniel Larimer wrote:
Upon closer inspection of include/osg/buffered_value I think I have
identified the REAL problem. There is a difference between Linux
and OS X
when it comes to allocating static variables.
Interesting. There should be no functional difference since this
behavior is defined by the C++ language. See the language reference
section 3.6.2 [basic.start.init] for details.
On OS X the static variables such as s_extentions get allocated
BEFORE
main(), but Linux doesn't allocate them until their first reference.
C++ mandates that a static variable is initialized the first time
control passes through its declaration. Both of these OS behaviors are
permitted by C++ with some caveats. Again see [basic.start.init] and
related sections.
Can you point me at the static variables that are misbehaving? I'd
like
to take a quick look at the situation and offer some help.
Regards,
Marcus
--
Mark Barnes
COLLADA Project Lead, tel:+1.650.655.7342
Sony Computer Entertainment America
http://research.scea.com
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
