On Fri, 2008-11-07 at 00:20 +0000, Chris Vine wrote: > > You have a static (shared) signal object. It couldn't be thread safe, > since it doesn't have any locking. It is just like any other class > object with data members (ie which operates on non-local data). > sigc::signal<>::emit() will amongst other things access the std::list > object maintained by the signal object to call operator() on the slot > object the list object holds (the slot object representing listener()).
this much i understood :) however, my assumption was that anything which manipulated the slot list would be thread-unsafe, but that read-only access (ie. traversing the list and invoking the slots contained therein) would be thread-safe to the extent that the code invoked by the slots is (in my real program and this test, that part is true). i do not understand why emit() would need to modify the list of slots in any way, and thus i don't see why it could not be thread-safe on the condition that the slot list is not modified during the "period in question". it is certainly possible to have two threads traverse a std::list<> simultaneously without any issues at all - its not clear why emit has to do anything more than this. i'd really like to understand why it apparently does. --p _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list