< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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


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