Re: [Boost-users] [signals (thread safe)] Scope of slot_call_iterator (or how to implement deferred signals)

Subject: Re: [Boost-users] [signals (thread safe)] Scope of slot_call_iterator (or how to implement deferred signals)
From: Fabio Fracassi (f.fracassi_at_[hidden])
Date: 2009-02-04 02:44:35

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