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

[Maciej Stachowiak <mjs noisehavoc org>]

On 29Oct2001 02:25AM (-0500), Michael Meeks wrote:
> 
> 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.

If you tell everyone to use this function. Plus people will see it in
the headers or docs or examples and assume they need it. It sucks for
all the same reason as explicit init functions suck (even optional
ones).
 
>         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. 

There's already got to be a nonstandard
"give_me_all_the_objects_that_have_not_been_freed_yet" function or the
like, right? It doesn't seem unreasonable to add a helper function to
make that one work better. There's no reason to think of it as a
CORBA_Object method, it doesn't need to do any CORBA or necessarily
even mark anything in the internal object struct - it could just put
the object on a list for the debugging function to ignore.

> I think adding an (optional)
> 
>                 int bonobo_activation_shutdown (void);
> 
>         is far more pleasant.

I would rather do `nasty' things in the platform libraries to make the
API seen by developers simpler.
 
> > 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.

Your argument boils down to: "I am doing something bad. But I don't
like your idea for how to fix it, therefore unless you accept my
solution (despite thinking it's bad design), then it's all your
fault."

I don't find this terribly convincing.

> > 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.

Yes, I understand that orginary CORBA reference leaks are bad,
however, this really has nothing to do with objects that are allocated
once and exist for the lifetime of the program by design.
 
>         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 ].

I think you will find a lot of people would run with the magic
variable because many gnome hackers nowadays use shared sets of build
scripts. But it's true that most normal users would not be running in
reference debugging mode.

>         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.

I certainly agree it's good to fix reference leak problems early.
 
>         So ... I find it hard to believe that we are proposing creating
> unneccessary ugly mess in Gnome 2.0 already.

I don't think we need to get melodramatic to solve this problem.


If you're really unwilling to add a way to make the reference leak
debugger ignore objects that have the same lifetime as the program,
then maybe we could consider naming the function something other than
bonobo_activation_shutdown. Perhaps bonobo_activation_debug_refcounts,
so it's clear what it does and that it's optional, so people won't
worry about calling it on abnormal exits or anything crazy like that,

Regards,

Maciej