Re: [reSIProcate] MessageDecorator API (was: memory management and asynchronous activity in TransactionState.cxx)
On 14/11/13 20:47, Scott Godin wrote:
>>> - to avoid disruption to existing MessageDecorator users, I'm likely to
>>> add some virtual method with a default implementation that calls the
>>> existing synchronous decorateMessage(), e.g.
>>>
>>> virtual bool decorateMessage(SipMessage &msg,
>>> const Tuple &source,
>>> const Tuple &destination,
>>> const Data& sigcompId,
>>> Fifo<TransactionMessage>&
>>> asyncHandlerFifo)
>>> {
>>> decorateMessage(msg, source, destination, sigcompId);
>>> return true;
>>> }
>>>
>>> and anybody who wants to do something more lengthy can override that
>>> method, start a thread, return false and post the result back on the
>>> fifo when ready. Does this seem like a reasonable way to avoid API
>>> disruption?
>>>
>>
>> [Scott] it would be better if existing applications didn't have any
>> performance penalties introduced as a result of adding async support.
>>
>>
>> An extra level of vtable indirection isn't going to hurt performance
>> here, at least not to any detectable degree. And the compiler _might_ even
>> be able to avoid it in this case because it is possible to determine the
>> concrete class, I think.
>>
>
> [Scott] I agree if that's what Daniel is actually proposing. I was
> assuming it was going to cause the creation of an async message that would
> be driven back into the processing loop and the decorator wouldn't be
> executed inline any longer.
>
It would not do every decoration asynchronously - sorry if that was not
clear
If the new method returns true, the decoration is done and processing
continues the way it does now without putting anything back into the FIFO
If the new method returns false, the decoration is not complete and the
subclass has to post the message (or some wrapper) back onto the FIFO
The old method could also be deprecated to encourage people to use the
new prototype