[reSIProcate] MessageDecorator API (was: memory management and asynchronous activity in TransactionState.cxx)

[Scott Godin]

Ok - sounds good to me then.  ; )

Scott


On Fri, Nov 15, 2013 at 12:30 PM, Daniel Pocock <daniel at pocock.com.au>wrote:

>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20131115/461868bd/attachment.htm>