Re: [reSIProcate] Fwd: [reSIProcate-commit] resiprocate 7077 nash:inside resip/stack/Transaction::process method contains complex
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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel