Re: should destroying set the refcount to 0?

[Nat Friedman <nat helixcode com>]

The reason bonobo_object_destroy exists is that, well, it shouldn't.
There are some cases where the proper operation of one object depends
on the existence of another.  And so if the independent object dies,
the dependent object should be unconditionally destroyed.  That was
the logic anyways.

But it doesn't make sense.  Really, the dependent object should notice
the disappearance of the independent object and behave appropriately;
blocking attempts to use it or emitting a signal or something to let
its user know.

There's another issue, too, somewhat unrelated, but vexing nonetheless
and desperately in need of being solved properly.  A lot of Bonobo
objects act as Gtk proxies for remote CORBA objects; that is either
their sole purpose (in the case of *Client objects) or a part of what
they do.  If the remote CORBA object fails irrevocably, the local
Bonobo object is basically useless.

And it should say something about this.

But for some reason, pretty much no Gtk/GNOME API methods return
errors.  So what we have now is the "system_exception" signal which a
BonoboObject will raise if it encounters a fatal exception whilst
conversing with the remote CORBA object.

I don't know if this is right.  I think it's not.  What we need is a
way of saying "I am now useless for communications with the remote
CORBA object."  I even wrote code for a signal called "i_am_useless"
once.  

When the exception is encountered, the local Gtk object should *die*.
It's completely useless.  Further attempts to use it will fail
(hopefully cleanly, if the object is well-written).

I've never felt satisfied with the way we deal with this issue in
Bonobo.

Nat

Maciej Stachowiak <mjs@eazel.com> writes:

> Christopher Blizzard <blizzard@redhat.com> writes:
> 
> > Maciej Stachowiak wrote:
> > > 
> > > Should bonobo_object_destroy set the refcount to 0? Right now, if you
> > > destroy the object, it does some cleanup (including
> > > gtk_signal_disconnects and gtk_object_destroys), but does not set the
> > > refcount to 0. If the refcount ever does hit zero, that cleanup tries
> > > to happen again, but fails.
> > 
> > Pardon my igornance but shouldn't the object's destructor be called as a
> > result of the refcnt being dropped to zero?  This would be the expected
> > behaviour, imho.  What is happening now?
> 
> It does get called as a result of the refcnt being dropped to 0 (well,
> not really, the code was cut & pasted, but Darin is going to fix
> that). The problem is if you destroy explicitly (which may happen as a
> result of code on the client side doing an explicit destroy), then
> later dropping the refcount to 0 will cause another attempted destroy
> and result in problems.
> 
>  - Maciej
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-components-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.