Hi Tanguy, On Wed, Aug 5, 2009 at 12:55 PM, Tanguy Fautre<[email protected]> wrote: > To come back to the deadlock issue, I don't think there is any way to fix it > without breaking the current OSG API compatibility. While I would favour > removing the singletons (and would heavily suggest other designs for OSG > 3.0), I perfectly understand and agree with you that such an approach is > unacceptable in the short term.
Um... I have yet to see a compelling reason for not using singletons like Registry or a decent proposal for a replacement. For OSG-3.0 my plan is to focus on refactoring just the core scene graph and how rendering is implemented, for the rest of the API changes we should keep as minimal as possible to try and reduce to headache of porting from OSG-2.x to OSG-3.x. We can't avoid refactoring the core scene graph state management to be able to do shader composition, but the rest of changes we minimize. > The least disruptive solution I can think of (while being quite robust) would > be to introduce an initOsg() and a destroyOsg() function. It's a fairly > common approach and is in fact the one mandated by MSDN regarding the > limitations of DllMain (and the deadlocks that may follow if violated). My gut reaction is YUK. Design wise, implementation wise and support wise I know it's a hack. > initOsg() would initialize and construct all the global variables of Osg when > called, while destroyOsg() would take care of the destruction of such objects. OK. So this uber initOsg() method would need to initialize all global variables and hence know about all global variance and hence be tightly coupled with all global variables. Now if you have a very simply set of libs to work with, and everything is fixed in it's relationship this might work, but... if you have a loosely coupled design that allows you to extend it at runtime what then?? For instance NodeKits... who inits these? Do we have explict init's for each NodeKit the user might use. What about NodeKits that are pulled in at runtime to enable the loading of a particular databases? > The benefits are twofold: > - The user would have a better control on the lifetime of the OSG and its > global variables (among other things, solving the deadlock issue exposed in > this discussion). > - The user would have the ability to reset the library in a predictable > manner, which is currently impossible. > > A few points should be observed: > 1. init/destroyOsg needs to be referenced counted (allowing multiple and > re-entrant initializations) > 2. init/destroyOsg needs to be thread-safe > 3. init/destroyOsg needs to be aware that osg is divided into several > components (e.g. osg, osgDB, osgViewer, etc). It would probably be needed > that the user can in fact select which components of osg he wants to > init/destroy (in which case points 1 and 2 need to be done per component). OK state all possible benefits and ignore the monstrous downsides such as tight coupling and blowing out of the water the extensibility that the OSG is known for. I sure want to see a good solution to the problems you are seeing but I won't idly stand by while the OSG is made less easy to use and less extensible. You go explain to all the thousands of OSG users that having to re-factor they code for no gain, whilst compromising in extensibility that just supporting your particular usage pattern. What we have at hand is very specific issue that occurs when a very specific set of things are done in a client application, it's not a general problem that requires a major re-factor. Careful initiation at your end may well be the solution. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
