On Wed, Jul 30, 2014 at 11:14 AM, Andrey Semashev 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.