Re: Signal memory leak.

[David Benson <daveb idealab com>]

connect_object is a misnomer -- the `slot_object' may not be
a gtkobject at all... comments in gtksignal.c explicitly allow
this.  The intent of connect_object is to switch the user_data
and object minimize the number of dummy functions.  (see the
api docs for an example)  I guess compatibility demands that
the slotobject to remain a gtkobject instead of a gpointer... sigh...

You may use gtk_signal_connect_object_while_alive to
achieve the effect you desire...

- Dave



On Sun, 9 Jan 2000, Karl Nelson wrote:

> > Karl Nelson <kenelson@ece.ucdavis.edu> writes:
> > >         cid=gtk_signal_connect_object((GtkObject*)w,"clicked",
> > >                                       (GtkSignalFunc)Foo,
> > >                                       (GtkObject*)w2);
> > 
> > You never destroy "w" and you keep adding connections, so it has
> > continuously increasing memory use (also the speed of
> > gtk_signal_connect() starts to get really crappy... we seem to have an
> > O(n) list append in there ;-)
> > 
> > memprof shows no actual leaks, a pointer to all memory is retained.
> 
> True, it is not a leak in the sense of being lost memory.  However,
> it is memory which is being taken from the system.  In libsigc, 
> all these cases got handled so that when a connection is shared
> between 2 objects has one partner broken it disconnects the other.
> What was the intent here?
> 
> 
> > >         gtk_object_sink((GtkObject*)w2);
> > 
> > w2 is destroyed but not w...
> 
> Should the user expect the connection to be severed or not?  If not
> then wouldn't the user get an error if they attempt to use this connection?
> 
> --Karl
> 
> 
> -- 
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with 
>                        "unsubscribe" as the Subject.
> 
>