Re: gtkmm 3.0.

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 25 Mar 2010 09:46:08 +0100
Murray Cumming <murrayc murrayc com> wrote:
> I'm sorry for not taking the time to consider this discussion fully
> right now, but I do want to revisit it properly for gtkmm 3. I hope to
> have time later. Right now, I'm not putting much thought into gtkmm 3
> because it's not clear when the (silly, unnecessary, IMHO)
> ABI-breaking GTK+ 3 will happen, giving us the (blameless)
> opportunity to do gtkmm 3.
> 
> Even if we don't change this, I hope we'll have the big discussion
> again (like we did for gtkmm 2) so we know why we've decided whatever
> we decide.

While we are on the subject of gtkmm-3, can I make one other suggestion
in addition to weak pointers, which will help safe and sane programming
with gtkmm far more than discussing whether a particular object is held
by smart pointer or not. That is for gtkmm to provide its own
thread-safe sigc::trackable class which can interface with the rest of
libsigc++.

The fact that a thread-safe version of signals, and their associated
connection objects and the like, is not provided is unfortunate but
something that can be lived with: a signal is a signal and the library
user can easily work out what threads might emit and connect to it and
make sure that only one in fact does so. The fact that sigc::trackable
is not thread safe is far worse, because it makes slots themselves not
thread safe.

Thus, once one thread has created a slot representing a method of a
class derived from sigc::trackable (say by connecting to a signal
object, or even by calling a glibmm/gtkmm function which takes a slot
as an argument), no other thread in the program can easily create a slot
representing ANY of that object's methods.  It is such a trap for the
unwary, and so counter-intuitive, that I think it should be dealt with.

I accept it is not gtkmm's job to rewrite libsigc++.  But I think it
could help out with trackability.  All that I think may be required is
a sigc::trackable variant which is able to take a thread-safe container
rather than mandating std::list as its container of disconnection slots
(if that container used locking I think that would make the code which
nulls the slots also thread safe as a synchronisation side effect,
although I would need to think about that - or rather spend more time
looking at the sigc::trackable code).

Chris