On Wed, 28 Jul 2010 15:27:07 +0200 Murray Cumming <[email protected]> wrote: [snip] > > A signal/slot interface does not feature in C++0x. If one were to > > be introduced into C++-1x, presumably it would be based on > > boost::signal2, which does not have these problems as it has been > > designed to be thread safe (and trackability is implemented > > differently). > > So isn't it instead just time to think about using a (copy of) > boost::signal2 instead of libsigc++? I think there has been discussion previously about importing things from boost, such as smart pointers. The problem with using individual boost modules is that something like signal2 would bring in other parts of boost with it. Those parts will be somewhat reduced once C++-0x is out, because presumably some of its threading and smart pointer stuff will be retired, but it would still be a significant import.
It would be better I suspect to fix libsigc++, which probably means redesigning trackability, which I don't believe the sigc++ maintainer is interested in. It would be a significant task and I hope Krzysztof is willing to take it on. When I deal with threads I like to do things in small chunks where everything is as self-explanatory as possible and side effects are minimised: one of the problems with highly complex code like libsigc++, which does a lot behind the scenes, is that just carrying enough in your mind to be satisfied about things like thread safety or exception safety becomes extremely difficult. Until I pointed out the difficulties with sigc::trackable some years ago (I posted a couple of bug reports), even the glibmm threading examples in the tarball were not in fact thread safe, though they had been written by a very competent programmer. If it helps, the way signal2 deals with locking is that it uses by default boost mutexes, but if a user has a single threaded program (or is using signal2 in a way which does not raise thread safety issues), a user can specify boost::signals2::dummy_mutex as the relevant template parameter type which makes all mutex operations a no-op. If a similar approach were taken to libsigc++ that might keep everyone happy, and the default could be reversed for libsigc++. That is, by default it is not thread safe and has no glib dependency; but it has a thread safe option which does have that dependency in any case where C++-0x mutexes are not available. signal2 also makes extensive use of boost::shared_ptr to control object lifetime in an effort to maximise thread safety: in particular, an object which has automatic trackability must be constructed on free store and managed by shared_ptr if it might be destroyed concurrently by one thread as another thread invokes one of its methods via a signal, although I do not suggest we go down that route. To that extent I think signal2 goes too far, and because of object dependencies their solution can never be completely effective anyway. Documenting what is and what is not thread safe (which I would be happy to do) can be just as useful. So far as concerns libsigc++ as currently designed, a post of mine a year or so ago set out how to program safely with libsigc++ at some length: but it goes too far the other way. sigc::trackable is grossly unsafe (in my view). Chris _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
