Re: bonobo-activation; freeing base services ...

[Michael Meeks <michael ximian com>]

Hi Maciej,

On Sun, 28 Oct 2001, Maciej Stachowiak wrote:
> I still think explicit shutdown functions are an udue burden on the
> programmer. I don't think memory debugging justifies them.

        I really being to think we are not communicating somehow.

        The programmer does not have to call the shutdown function, it is
optional - consequently there is no extra burden.

        However, the shutdown function does return a very useful piece of
information - whether any CORBA objects leaked. This is extremely useful
to make automated regression tests fail - so you know there is an issue at
make check time.

        The alternative: of making the warning a g_error in the ORB, and
having a conditional atexit method inside bonobo-activation seems
incomparably nastier.

> What do you think of my suggestion to be able to mark particular
> objects immortal?

        I think that adding a method to the ORB something like:

        ORBit_another_nonstandard_C_method_ignore_this_object (object)

        is not a pleasant solution. I think adding an (optional)

                int bonobo_activation_shutdown (void);

        is far more pleasant.

> That seems like a cleaner solution and it would take the noise out of
> your regression tests.

        Well - the current solution seems the best from my position; I
free up the resources that bonobo-activation allocatd in libbonobo before
I shut the ORB down. A horrendous breach of encapsulation - yes; worse, it
seems I'll have to lookup some base services and unref them multiple times
to get it truly clean, but if that is your preferred solution - so be it.

> Clearly not freeing the ORB or the base services in bonobo-activation
> is harmless except for the warning noise, so let's remove the noise
> instead of putting the burden on application developers.

        The noise is highly useful debugging, and regression indicating
output, flagging leaks. During the normal course of running an application
a CORBA reference leak can manifest itself as eg. a leak of file handles.

        It is _really_ important to try and address these leaks, as they
are created - and one good way of this is having a simple way to make
programs warn on shutdown without defining some magic variable [ people
that create leaks should get to fix them, not just me who happens to run
with some obscure variable defined ].

        The reference leaks are also somewhat extremely difficult to find
- binary chop being a favorite approach. Consequently the earlier they are
warned of the better, then the programmer has a chance to notice his
mistake quickly.

        So ... I find it hard to believe that we are proposing creating
unneccessary ugly mess in Gnome 2.0 already.

        Sigh,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot