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