On Thu, 25 Mar 2010 09:46:08 +0100 Murray Cumming <[email protected]> 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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
