Re: [sigc] using libsigc++ in multi-threaded app

[Christopher E Kuklewicz <chrisk MIT EDU>]

I used (two) threads way back with licsigc++ version 1.0 (as a hobby)

When version 2.0 is final, I will go back and update my code.

There was a second method that also worked with version 1.0.

I will describe how it was done before...the new version may be easier
or harder to adapt.

My system depended on an STL collection of emission events.

The signal (from the gui thread) was connected to a special class that
absorbed the event and posted the event (with its parameters) to the
collection in a thread safe way (locking access to the collection).

The main loop of the background thread checked and could block on the
STL collection.  A simple producer / consumer arrangement.  When it
wanted to consume an event, it popped it out of the collection and
called the special class deliver the event.

Sort of sketch:

MyCollection myCollection;
Signal<void,int> source;
Slot<void,int> sink;

The connecting was done using a tempated "wrap" function:

source.connect( wrap( myCollection, sink ) );

Many signal sources can be connected to the same instance of
MyCollection.

"wrap" would create a listener class that caught each emission and
pushed a special class (with the int parameter and the sink) into
myCollection.  Later the background thread would grab the special class
and tell it to send the int parameter to sink.

Using a thread safe MyCollection like this works well with many threads,
and is very C++.  But blocking on many collections at once would be a
problem.

The second method used a pipe.  The "wrap" function made a special class
and wrote a pointer to the special class into the pipe.  The consumer
could check the pipe or block on the pipe's file descriptor.  Once the
pointer was read out of the pipe, the special class could be told to
deliver the signal.

Of course, while the special class is "in the pipe", no one is managing
the memory of the class.  If the reader dies then the memory is leaked.

One could add a pipe to MyCollection simply to have a file descriptor to
block on.  Instead of writing the pointer, I could just write a
meaningless token into the pipe.

The interesting this is that the special class need not be destroyed
after delivering the signal, the collection could keep an archive.  Thus
one could record a whole sequence of events to be played many times, or
never recorded.  One could modify MyCollection to one keep a finite
number of events (e.g. a single event, either the first or last).  One
could make an "undo" collection of events that are only delivered if the
user selected "edit->undo".

-- 
Chris Kuklewicz

On Thu, 2003-12-11 at 13:23, Jessee, Mark wrote:
> Hi,
> 
> I'm new to libsigc++ and am considering using it
>  in my application instead of a custom event
>  notification scheme.  How well suited is it
>  to a multithreaded environment?  In my app one
>  thread will be emitting the signal that will be
> processed by slots in other threads. 
>  Is there a way to do this in libsigc++?  
> Or would I have to come up with my own scheme
>  using command pattern or function objects?
> 
> Thanks,
> Mark
> _______________________________________________
> libsigc-list mailing list
> libsigc-list gnome org
> http://mail.gnome.org/mailman/listinfo/libsigc-list