On Thu, 29 Jul 2010 01:45:04 +0100 Chris Vine <[email protected]> wrote: [snip] > But, as I say, it is the thread safety of remote trackable objects > which seems to me to be the more pressing point.
The gory details of my conclusions when I last looked at this are coming back to me, and as you have probably by now concluded it is not as simple as that. When the destructor of a remote object deriving from trackable nulls any slots referring to its methods, those slots will be nulled in the thread in which the destructor executes, which may not be the thread which "owns" a particular signal object which might emit on the slot. If and when that other thread does emit, the slot may (as far as its memory visibility is concerned) be in an inconsistent state. The problem would be even worse if the remote trackable not only nulls the slots, but also removes them from the signal object (I cannot now recall whether it does that or not, but I suspect that it does). So in practice it is probably impossible to make trackable meaningfully thread safe without also making signals and connection objects thread safe. Chris _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
