Re: [[gtkmm] Glib::RefPtr also for Widgets?]

[Paul Davis <pbd op net>]

>> in my experience, it is extremely dangerous for many widgets, at least
>> in gtk+ 1.2 and its matching gtkmm version.
>
>Is "many widgets" some well defined set of widgets, or you mean "most
>widgets I used"?

i can't recall the specific set that i've had problems with, but it
includes buttons, clists and windows.

>I have multithreaded program, but only the main thread uses gtk/gtkmm.
>Other threads are workers only. And what do you mean by "one where memory
>allocation might happen after the "delete this" but before the end of
>signal emission" ? 

	thread 1:                          thread 2:
        ---------------------------------------------
	start signal emission
	delete this
					   new Foo;

        finish signal emission					   

there is every chance that the memory associated with the widget for
which the signal emission was occuring has been reused for a "Foo".

		    Of course 'delete this' is called in main thread where
>windows are created and signals are handled, and of course when I delete
>this object I don't alloc any memory in this thread. But other threads are
>free to do it and they surely do allocs.

unless you are using a highly customized version of malloc(3) such as
libhoard or the (terrible) one that comes with linuxthreads but is not
used by default, memory released by one thread can be reused by another.

>> deleting a widget during a signal emission is just a bad idea, IMHO.
>
>You can always do a little trick:
>In signal handler add a timer callback and bind 'this' pointer as a param
>to the callback, and the only thing that callback does is 'delete param'
>:)

thats what the template function i showed did, except it uses the idle
callback, not a timer. 

>Could you provide a simple example when 'delete this' causes troubles?

try deleting a button widget from the middle of a button_press event
handler. add a second handler for the same widget and event and
connect it after the first handler. then run the program. if the
second handler tries to do anything to the widget, it is operating on
free'd memory. if it allocates any heap, there is a good chance that
the second handler will cause a segfault even before returning to the
core of GTK+. 

and note that for button press events, GDK/GTK automatically tries to
set up a pointer grab so that the button release comes to the same
widget. oh, except that you just deleted it ...

--p