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

[Adam Roach]

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