Thanks Nat, I didn't know about this yet (noob!)
From a quick perusal (almost bed time :) !) I can't see how I would achieve my aim, which is:
1. create the "event" (signal) which is associated with a member function "callback" (slot). Associate a thread with the event
(can I create a signal connected to a slot which is a member function?)
2. in any other thread, call "post" (sig(data)) where data is a shared_ptr
3. the callback (slot) is called, running in the context of the *other* thread (the one originally associated with the "event" / (slot).
I'm trying to encapsulate a generic inter-thread messaging system where objects are passed around between threads, and associated with a member function which is designed to process said objects.
This design is essentially a messaging system between threads - for a simple example - we have a producer/consumer thread model. The consumer thread is encapsulated in a class (eg: class consumer_thread), which has a member function (eg: void consume(struct data)). The producer creates an "event" object which is associated with the consumer_thread object, it's void consume(struct data) member function, and the thread which must process the data (consumer_thread). Now when the producer produces some data, it calls event->post(data), which queues up an object which records the class instance and it's member function which must be called with parameter "data", and a shared_ptr to data. The consumer thread wakes up, gets the top of the queue, and calls obj->mem_fun(data) --> ergo, mem_fun is called in the correct thread context, and has the argument "data" to consume.
Does that make any sense? I don't think I'm explaining it well. Any suggestions, (how to do what I'm asking for, or trashing my design and offering a better design), would be greatly appreciated!
TIA
Steve
On 2 June 2010 19:06, Nat Goodspeed
<nat@lindenlab.com> wrote:
Steve Lorimer wrote:
I am wanting to write library code that will allow a user to create an "event" which is associated with a thread, a class instance, and a member function of that class. The user can then "post" data (generalised number of arguments) - which results in the class instance's member function being called in the context of the associated thread.
Steve, sorry if this is a stupid question, but by what delta does Boost.Signals2 fall short of your requirements?