On Wed, 28 Jul 2010 18:33:31 +0200 Murray Cumming <[email protected]> wrote: > 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.
There are four levels of thread safety to look at, in roughly ascending order of difficulty: 1. Make sigc::trackable thread safe. This means that having constructed one slot for an object deriving from trackable, you are not then prohibited from constructed any other slots for non-static methods of the object in another thread. 2. Make sigc++ signals thread safe. This means that once any one thread has constructed and connected to a signal, any thread can emit on it. (The connected slots would of course execute in the thread which emits, we are not talking about inter-thread communication here.) 3. Make sigc::connection objects thread safe. This means that if one thread has constructed and connected to a signal, another thread can block or disconnect the signal. (Note: sigc::connection inherits from sigc::trackable.) 4. Make connected objects thread safe. This means that you can emit on a method of an object while another thread is trying to tear it down. Of these, 1 seems to me to be essential, and 4 is self-indulgent, even though boost::signal2 tries to do it (and it seems to me also to be impossible because of object dependencies). 2 and 3 probably require a re-write and can't be done within gtk+-3 timescales. 1 above should be achievable within those timescales: however, I looked at this and I found the sigc++ code very, very difficult to tease out because of the way it is built [1]. If Krzysztof could give it a try that would be great. Chris [1] In the end, it was less effort to write my own minimalist thread-safe signal/slot classes which do 1 to 3, which I can use when I need them. _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
