[reSIProcate] Fwd: [reSIProcate-commit] resiprocate 7077 nash:inside resip/stack/Transaction::process method contains complex

[Derek MacDonald]

I've spent some time walking the TransactionState change, and I agree
that the TransactionState code is confusing; however, given the
contract of TransactionState the change(if any) shouldn't extend
beyond that component.

First, TransactionState receives(pulls) a message from the StateMacFifo.

It can then:

1. Call TransportSelector::transmit(not an ownership transfer), and
possibly assign that message to MsgToRetransmit.
2. Send the message to the TU(ownership transfer)
3. Generate a msg, and either send it to the TU , or assign it to
msgtoretransmit

Since we are concerned about object lifetime, we can ignore the
TransportSelector. I'll also state that we don't have a leak issue wrt
to MsgToRetransmit, as it can be cleaned up in the TransactionState
destructor.  Sending a msg to the TU is ownership transfer, and
shouldn't result in a leak.

The key point is that we can scope any changes to the TransactionState
file. If we do have a leak in TransactionState, we might be able to
make memory ownership more explicit w/ auto_ptr. I don't believe
shared_ptr should be used because of its viral nature.

However,  and we *really* shouldn't change TransactionState until we
have a test which reproduces this issue.

-Derek




On 4/17/07, Adam Roach <adam at nostrum.com> wrote:
> Nash Tsai wrote:
> > SharedPtr usage in this context, fifo and no multi thread access, can
> > hardly goes wrong,
>
> That's simply not true -- handing a pointer to a SharedPtr is enough to
> put everything in play that is necessary for eventual spectacular
> failure. If you don't understand this, then my previous message failed
> to convey its point. Please re-read it carefully. If you still don't
> understand why this has nothing to do with threading after a careful
> re-read, let me know and I can try to clarify.
>
> I'm not saying "don't use smart pointers". I'm saying "smart pointers
> have some pretty severe caveats and incur high -- sometimes staggering
> -- development costs. If you find a place where they save more work than
> they cause, then a cautious use of them is appropriate. But please
> consider that the cost associated with using them is quite high, and so
> the barrier to using them should be similarly high."
>
> In this case, I have a very hard time believing that the amount of work
> being _saved_ by the use of smart pointers is even 1/20th the amount of
> work that will be _caused_ by supervising the ownership of all SIP and
> Application messages via smart pointers.
>
> /a
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>