On Tue, 27 Jul 2010 16:51:52 +0200 Krzysztof Kosiński <[email protected]> wrote: > W dniu 27 lipca 2010 11:01 użytkownik Murray Cumming > <[email protected]> napisał: > >> 1. sigc::trackable is not threadsafe. > > > > A patch for this could make a break far more likely. I wouldn't > > want to do 2 breaks. > > The easiest way to fix this is to allow sigc++ to depend on Glib when > it's present at build time. In addition to being able to use Glib > mutexes, we could use the slice allocator. Since the predominant use > of libsigc++ is within gtkmm, this would not add an extra dependency > in 95% of cases, and in the remaining 5% it could be turned off at > build time. Is this OK?
When I was looking at this, I did some thinking about whether, by analogy with the std::queue container type, the slot container type for sigc::trackable (which is at present a std::list object) could be specified as a template type. In that way you could have std::list as the default, but also enable a user to specify a thread safe container type in its place when needed. In the end I think I concluded that a thread safe implementation doing it this way would be extremely difficult to achieve, for a reason I can't now remember. (I also ended up with the view that retaining trackability as a property of the object whose methods the slots represent, rather than a property of a signal connection, was also difficult to achieve in a thread safe way.) However, if you are planning on fixing sigc::trackable it may be worth looking at the templated container type approach. Chris _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
