Hello, On 5/3/07, Andy Spitzer <[EMAIL PROTECTED]> wrote: > Essentually, either a second lock is required, or one must be assured that > there are no other threads that could possibly access the object before it is > destructed. I believe that much of sipX uses the later approach, although it > seems to be an unwritten rule, and could possibly be violated. Locking > "yourself" just before destruction seems like a good idea, but as you so > rightly > pointed out, it doesn't really work! Yes, I believe we should try to use second pattern when possible. Pointers to object should be cleaned up from everywhere before deleting it. If someone keep pointer to deleted object it will lead to crashes even if mutexes are not involved. Though, locking in destructor *may* help to lower number of crashes in release code in case logic was broken and someone still point to this object, but this "safety" will be achieve in price of one more locking, so for transient obejcts it may cause some performance degradation. So, we should always prove that objects will not be accessed when it's going to destroy. I believe it's right way.
-- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
