Re: [Boost-users] [bind] & [function] How do I store member functions with generalised arguments for later invocation?

Subject: Re: [Boost-users] [bind] & [function] How do I store member functions with generalised arguments for later invocation?
From: John Dlugosz (JDlugosz_at_[hidden])
Date: 2010-06-02 18:25:34

I'm thinking of the same thing, and would reach for std::tr1::function generalized function objects to be the callback object queued between threads.  between 'function' and 'bind', both standard now, it should do the trick.  This will play nicely with compiler-native lambdas when they are available to your project, too.

From: boost-users-bounces_at_[hidden] [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Steve Lorimer
Sent: Wednesday, June 02, 2010 4:36 PM
To: boost-users_at_[hidden]
Subject: Re: [Boost-users] [bind] & [function] How do I store member functions with generalised arguments for later invocation?

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_at_[hidden]<mailto:nat_at_[hidden]>> 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?

_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]<mailto:Boost-users_at_[hidden]>
http://lists.boost.org/mailman/listinfo.cgi/boost-users



TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.