On Wed, Jul 30, 2014 at 11:14 AM, Andrey Semashev <andrey.semashev@gmail.com
wrote:
The problem with the callbacks is that you have to choose the thread to invoke them in. In the simplest case this could be the writer thread, in other cases a separate thread pool might be more desirable.
Indeed. In the general case, a nice interface would let the user decide how the callback would be called. Maybe using an optional Executor concept object as first argument to the callback subscription function would be enough (as for future.then() ) In my specific use case, just calling the callbacks in the thread that update the value is ok because I always assume (in all my code) that a callback will do it's own synchronization work if it's necessary. That's why in my initial example there is a work queues used in the callback. Now that I think about it, using an executor is a generalization of the same idea, only the point of decision of how to execute the callback's code is changed. Assuming the work queue match the Executor concept, this code: m_foo_count.on_changed( [this]( int new_value ){ m_work_queue( [=]{ on_foo_count_changed( new_value ); }); }); could be simplified to: m_foo_count.on_changed( m_work_queue, [this]( int new_value ){ on_foo_count_changed( new_value ); }); (or the equivalent using bind) But the generated code would be like the first snippet, just a wrapping.