Re: [sigc] why is this simple test program not thread-safe?

[Paul Davis <paul linuxaudiosystems com>]

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