Re: [sigc] why is this simple test program not thread-safe?
- From: Chris Vine <chris cvine freeserve co uk>
- To: Paul Davis <paul linuxaudiosystems com>
- Cc: libsigc-list gnome org
- Subject: Re: [sigc] why is this simple test program not thread-safe?
- Date: Fri, 7 Nov 2008 00:20:23 +0000
On Thu, 06 Nov 2008 22:44:12 +0100
Paul Davis <paul linuxaudiosystems com> wrote:
>
> the following simple test program will randomly crash (always in the
> same place). the backtrace makes it seem reasonably likely that
> sigc::signal::emit() is not thread safe - i.e. an application must
> ensure that only a single thread is emitting the same signal at one
> time.
>
> if true, this is a major setback to my understanding of sigc++. i knew
> that it was not threadsafe to connect new slots to the signal without
> mutexes, but i was under the impression that emission was safe.
[snip]
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()).
The other issue (discussed in earlier exchanges of postings) is that
signaller() has a C++ linkage specification but is passed to
pthread_create( ) which has a C linkage specification for its function
pointer argument - but this is not a problem with g++.
Chris
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]