Hi Robert,
What you are describing seems to me like a convenience shortcut, but not motivated by technical limitations. Most of the time it's neat that this happens. But again, OSG is making too many decisions there. Too much magic is happening, and there is no room for customizations. >From what I've understood/seen, several plugins are already loaded by default. >But why is OSG deciding what is default and what isn't? When needed, the >application should be able to have a full control on which plugin get >registered, and which does not. Same goes when a plugin is registered. Why does the plugin decides which file extensions it is responsible for? Why does it decide that it should be used for the whole application? It's not the responsibility of the plugin to decide when it should be used, it's the application's responsibility. I admit that my understanding of osgDB::Registry is limited, but I can already sense a problem when an application would try to load several plugins that declare themselves responsible for the same file extensions (e.g. the Xine, the QuickTime and our FFmpeg cover pretty much the same file extensions). I'm using osgDB::Registry as an example, as it shows how OSG is taking responsibilities and decisions that should be left to the applications. The way I perceive it, OSG is using singleton most of the time as convenience. Most applications only need one osgDB registry, so OSG implemented it as a singleton. The plugin magic can happen transparently, and most applications are happy. But if an application does not want the default behaviour, it should be able to get its hands dirty. By using singletons as convenience, OSG is taking too much decisions that cannot overridden, too much magic happens behind the curtains. Exposing these objects (e.g. readNodeFile() that takes a reference to a registry, instead of an implicit reference to a singleton) makes the application more aware of the objects and their semantic, and there is no more magic behaviour. It also makes it easier for an application to override these objects (e.g. by polymorphism) or control their states. The fact that an application cannot manage the lifetime of OSG's globals is in our case a major issue, and sometimes just plain wrong. Default convenience could be provided by an extra layer either in an extra OSG library or by the application itself. But at least, the application gets to make the decisions about it. I think that the C++ standard library is a good example of such a design, where the defaults are fine for most applications, but where an application can almost override everything if needed. In other words, the application itself makes the decisions about the balance between convenience and what it wants to handle. Tanguy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Osfield Sent: Thursday 12 February 2009 16:47 To: OpenSceneGraph Users Subject: Re: [osg-users] memory leak false positives on Windows Hi Tanguy, The use of Registry Singleton is to primarily to facilate loose coupling of plugin implementations from application code. The plugins use a proxy object that when constructed automatically registers itself with the Registry making itself available for the whole application to use. This system allows us to put ReaderWriters into applications, into plugins, or even have multiple ReaderWriter's embedded in a single application or library. This systems is extensible and very loosely coupled. Without the use of a Singleton how would do it... we'd have to explicitly link in all the ReaderWriters that we needed, we need to explicitly list all the DotOsgWrappers, so rather promoting loose coupling, we demote it. Perhaps you have a clever solution for this... I'm all ears. Robert. On Thu, Feb 12, 2009 at 4:26 PM, Tanguy Fautre <[email protected]> wrote: > > It seems to me that OSG often uses singletons as a user convenience. > For example, because the osgDB registry is a singleton, one can simply write: > > osgDB::readNodeFile(file_path); > > Instead of having to have a handle to a registry object: > > osgDB::Registry plugins; > > /* ... */ > > osgDB::readNodeFile(file_path, plugins); > > > Which is great most of the time, 'cause you don't want to pass a > osgDB::Registry references all over the place. > > However, such a convenience comes at a high cost that is not necessarily > obvious at first (see my previous post). > > Implementing a singleton implies that there can only be one instance > (although the "per-what" part is ambiguous). This is usually not motivated by > a technical limitation, but by the developer who fails to see the need for > more than one instance. Such assumptions are not necessarily wrong, but they > do often put artificial limitations on how a class can be used (e.g. why > can't I maintain two osgDB::Registry instances that have different plugins > registered?). > > > In the case of OSG, my main complains with its use of singleton are: > > - We cannot control the lifetime of objects created by OSG. OSG makes that > decision for us, but we don't want OSG to tell our application what it should > do. I expect OSG to do what our application tells it to do. > > - Because of this, OSG singletons are broken when using multiple DLL/EXE and > static libraries in an application. Our team had to call several obscure OSG > release functions to work around the problem. > > - The state of the application is changed magically and subtly by user > function calls that seems unrelated. Because OSG is managing hidden global > objects that are not exposed to the user, it makes it very difficult to > understand the (global) states that are changed by some function. > > > I'm not saying there is no reason to use singletons in OSG. Quite the > contrary. But I think that before using a singleton, it should be carefully > considered whether it's due to a reasonable technical limitation or whether > it's a mere convenience. What I don't like is that fact that currently OSG is > deciding for me that my application should always use singleton implemented > by OSG just for convenience, imposing all the limitations that go with it. > > IMHO It should be possible to provide convenience and flexibility. For > example, OSG 3.0 could be designed so that it minimizes the use of > convenience singleton, and instead provide an extra "convenience" > layer/library for applications that are happy with the default singleton > behaviour. > > > Tanguy > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Sukender > Sent: Thursday 12 February 2009 13:35 > To: [email protected]; OpenSceneGraph Users > Subject: Re: [osg-users] memory leak false positives on Windows > > Hi Tanguy, Robert and Gordon, > > IMHO, there is no unique "singleton" pattern, but as much as existing > implementations. The fact is that there is no perfect singleton, all have > benefits and drawbacks. Several attemps were made to create a generic > singleton (See boost.singleton candidate lib), but I never saw one that fits > any use, and even in boost.singleton lib you don't have one, but multiple > singletons. > I agree we may not throw away singletons (in general, not specifically > talking about OSG), but we have to carefully understand, what each singleton > does and does not, and then document and test it. > > Thus, I suggest we create systematic unit tests (when 2.8.0 would be behind > us) to ensure our singleton(s) do what we expect from them on *ALL* platforms > supported by OSG. Maybe this could be the same for other low-level and/or > cirtical code. > Your thoughts? > > Sukender > PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ > > > Le Thu, 12 Feb 2009 14:10:42 +0100, Gordon Tomlinson > <[email protected]> a écrit: > >> Interesting claim on singletons ;) >> >> I have to agree with Robert, singletons are an extremely useful tool but one >> does have to understand they have limitations due to in general their static >> nature and I also have disagree that pattern is broken, like anything they >> can be missed used or over used, but I don't really see that in the OSG >> core >> >> The biggest issue I find is that so many programmers have no real >> understanding of what the key word 'static' means to the life time of any >> variable, whether a POD or a singleton and that's the real problem ( and I >> know a lot of guys that are actually very good developers/programmers that >> do not understand the lifetime), now you compound this issue on today's PC >> that now finally support real multi- processors and threaded apps sadly >> many yet simply do not have the back ground, experience, training again to >> understand the life of a static in those arenas or developed apps that are >> fully multi-processors and thread >> >> This is good for old fossil idiots like myself and many on this list who cut >> our vis-sim teeth on good old SGI and it wonderful multi-processors threaded >> hardware/software environments, nothing like working with 32 processors, 14 >> graphics window outputs, 8 external various sim-engines feeding live in, >> add in quite a few in DIS/HLA connections now those were the fun days ;) >> >> Just in case I don't mean to say y'all don't understand , just that there a >> lot that don't more than you would think and I find that scary ... >> >> ____________________________________________________________________________ >> __ >> Gordon Tomlinson >> >> [email protected] >> IM: [email protected] >> www.vis-sim.com www.gordontomlinson.com >> ____________________________________________________________________________ >> __ >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Robert >> Osfield >> Sent: Thursday, February 12, 2009 7:32 AM >> To: OpenSceneGraph Users >> Subject: Re: [osg-users] memory leak false positives on Windows >> >> Hi Tanguy, >> >> I'm afraid I disagree with you on your assessment of the value of >> Singletons. Yes you have to implement them correctly, but that goes >> with any solution for managing resources, throwing out use of >> Singletons doesn't not solve problems, it just introduces new ones. >> >> Robert. >> >> On Thu, Feb 12, 2009 at 12:00 PM, Tanguy Fautre >> <[email protected]> wrote: >>> Hi, >>> >>> I know this is a bit OT, but talking about OSG design... What about >> dropping the singleton pattern entirely? >>> The more I use it or the more I encounter it, the more I think the >> singleton pattern is completely broken. I know this is quite a bold claim, >> but bare with me and let me explain. >>> >>> >>> - The life time of the singleton is not well defined in most cases, >> leading to typical problems in C++ such as the initialization order problem. >>> >>> - The singleton pattern is an ambiguous design. It states that there is >> one instance, but it does not state "per what". Is it per thread? Is it per >> process? Is it per library/DLL? Is it per application? Is it per OS? Is it >> per computer? >>> >>> >>> These two reasons alone make the typical singleton pattern broken in a lot >> of cases. Most of the time without the programmer realizing it (myself >> included). Anyone having to deal with singletons, static libraries and DLLs >> knows how dangerous it becomes (e.g. you can often have several unwanted >> instance of the singleton: one per DLL/EXE). Add thread-safety into the mix, >> and it all becomes a nightmare. >>> >>> We've had already several problems with OSG in our project due to that, >> and had to resort to ugly work arounds (e.g. manually calling undocumented >> OSG release functions). >>> >>> >>> May I suggest that a better design is investigated for OSG 3.0? >>> >>> For example: >>> >>> class Initializer : private noncopyable >>> { >>> public: >>> >>> Initializer() >>> { >>> if (m_ref++ == 0) >>> initializeGlobalInstances(); >>> } >>> >>> ~Initializer() >>> { >>> if (--m_ref == 0) >>> uninitializeGlobalInstances(); >>> } >>> >>> private: >>> >>> initializeGlobalInstances(); >>> uninitializeGlobalInstances(); >>> >>> atomic_counter m_ref; >>> }; >>> >>> >>> Such as solution clearly defines the lifetime of the OSG library. It also >> puts the responsibility of managing the lifetime of the library in the user >> hands, who's more apt to know what is right for his application. It's also >> exception-safe. >>> >>> Note that that implementing >> initializeGlobalInstances/uninitializeGlobalInstances as thread-safe needs >> careful thinking (see >> http://www.justsoftwaresolutions.co.uk/articles/implementing_mutexes.html >> especially the part about initialization and uninitialization). >>> >>> Also note that the Initializer has to be implemented in a DLL (i.e. shared >> library) and not a static library, as it does not solve the multiple >> singleton instances per process problem. However, I'm currently not aware of >> any robust ways of solving that problem. >>> >>> >>> I hope I don't come as too arrogant on this. But I really think this part >> of OSG doesn't do justice to the rest of the library. >>> >>> Cheers, >>> >>> Tanguy >>> >>> >>> -----Original Message----- >>> From: [email protected] >> [mailto:[email protected]] On Behalf Of >> Jean-Sébastien Guay >>> Sent: Wednesday 11 February 2009 16:21 >>> To: OpenSceneGraph Users >>> Subject: Spam: Re: [osg-users] memory leak false positives on Windows >>> >>> Hi Cory, >>> >>>> I don't think anybody has questioned the design of OSG. >>> >>> Yes, Neil has said that perhaps we should consider "restructuring" to >>> avoid the false positives. This comes down to changing the design. >>> >>>> I also agree with you that making code concessions to accommodate tools >>>> is unfortunate, but it happens all the time. >>> >>> Yes, the coding changes to accomodate tools. But the design will stay >>> the same. It's the implementation that changes. That's what I was >>> talking about. >>> >>>> On the other hand, I'd like to know if code that explicitly unloads >>>> OSG would ever be accepted into the repository. I'm getting the sense >>>> that it would be if it were sufficiently transparent, simple and >>>> inexpensive. >>> >>> Yes, Robert said in this thread that he would accept something that >>> unloads/unrefs all singletons / static objects, but it might be hard to >>> get to all singletons since some exist in the implementation files only. >>> >>>>> (btw, has anyone compiled valgrind for Windows?) >>>> valgrind is Linux only. >>> >>> I suspect it's not Linux-specific, but more gcc/g++ specific, and so >>> might be buildable on cygwin or mingw? If it is, then it might be usable >>> for Windows executables... >>> >>> J-S >>> -- >>> ______________________________________________________ >>> Jean-Sebastien Guay [email protected] >>> http://www.cm-labs.com/ >>> http://whitestar02.webhop.org/ >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
