[signals (thread safe)] Scope of slot_call_iterator (or how to implement deferred signals)
Hi,
I am currently trying to implement deferred signals using boost signals
(well thread safe signals). I had the (crazy?) idea that it might be
possible to hijack the combiner interface to do this.
The design rational said that during the signal call the state
(including the arguments that were passed) are cached for the combiner.
So, what I tried to do was to copy and store the first and last iterater
out of the combiner, to iterate over them at a later time, to call the
slots. What I don't know is whether the slot_call_iterator (and the data
it uses ) stays in scope after the signal call (i.e.
signal...::operator() ) returns.
Here is what I tried:
#include
On Tuesday 03 February 2009 18:15, Fabio Fracassi wrote:
I am currently trying to implement deferred signals using boost signals (well thread safe signals). I had the (crazy?) idea that it might be possible to hijack the combiner interface to do this.
The design rational said that during the signal call the state (including the arguments that were passed) are cached for the combiner. So, what I tried to do was to copy and store the first and last iterater out of the combiner, to iterate over them at a later time, to call the slots. What I don't know is whether the slot_call_iterator (and the data it uses ) stays in scope after the signal call (i.e. signal...::operator() ) returns.
It's definitely not safe to do that with the current implementation, it's not a usage I've considered before. It does seem like it would be possible for the library to support what you want to do, adding a feature to the slot call iterators similar to what boost::shared_container_iterator provides. My current priority is to actually get the library into a release over adding new features though. My expectation was that someone doing what you are trying to do would bundle up the arguments on their own in their slot, to send them off to wherever. It does seem like it could be a convenience to let them copy the slot call iterators out of the scope of the signal invocation, since the signal has already internally bundled the arguments.
Frank Mori Hess schrieb:
On Tuesday 03 February 2009 18:15, Fabio Fracassi wrote:
I am currently trying to implement deferred signals using boost signals (well thread safe signals). I had the (crazy?) idea that it might be possible to hijack the combiner interface to do this.
The design rational said that during the signal call the state (including the arguments that were passed) are cached for the combiner. So, what I tried to do was to copy and store the first and last iterater out of the combiner, to iterate over them at a later time, to call the slots. What I don't know is whether the slot_call_iterator (and the data it uses ) stays in scope after the signal call (i.e. signal...::operator() ) returns.
It's definitely not safe to do that with the current implementation,
I was already beginning to fear that to be the case.
it's not a usage I've considered before. It does seem like it would be possible for the library to support what you want to do, adding a feature to the slot call iterators similar to what boost::shared_container_iterator provides.
I think that I will have a look into this.
My current priority is to actually get the library into a release over adding new features though.
Quite understandable. I guess such a feature would also add a bit of overhad, so for the normal usage it might have to be turned of.
My expectation was that someone doing what you are trying to do would bundle up the arguments on their own in their slot, to send them off to wherever.
For a single signal I would do just that. But as a general feature where users of the code can send deferred signals with arbitary arity this is not so easy. I would have to replicate the whole "variadic parameters" handling for this to work, wouldn't I?
It does seem like it could be a convenience to let them copy the slot call iterators out of the scope of the signal invocation, since the signal has already internally bundled the arguments.
Exactly, and it would avoid duplicating the mechanisms involved. Thank you Fabio
participants (2)
-
Fabio Fracassi
-
Frank Mori Hess