On Wed, 2010-07-28 at 16:49 +0100, Chris Vine wrote: > 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
I'm probably the maintainer right now. I'm not against it if I can understand it. > 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 > > -- [email protected] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
