I think you got it. It is the caller's problem to not break the calling convension. In cases where the object might be released by the caller due to threading or rentrance, it is the caller's responsibility to do whatever it takes to avoid the object being deleted. This generally means a stack-local addref/release pair (nsCOMPtr is *ideal* for this). That is why you will sometimes see code in mozilla that lookes like:
nsCOMPtr<nsIFoo> kungFuDeathGrip(mFoo); bar->foo(kungFuDeathGrip); NB: 'kungFuDeathGrip' is a technical term in the mozilla universe. And, often the object being protected is 'this' and/or the object that we are trying to call: nsCOMPtr<nsIFoo> kungFuDeathGrip(this); DoSomething(kungFuDeathGrip); or nsCOMPtr<nsIFoo> kungFuDeathGrip(mFoo); kungFuDeathGrip->foo(); John. Tobias Oberstein wrote: >> What you are worried about is the life time of the object pointed to >> by a inteface pointer. There is a guaranteed that all XPCOM object >> will exist until the last reference to them is owned. So, in your >> example, the caller had to have a reference to this object. > > > > Ahh. Naive question. The caller is invoking the method _synchronously_, > that is its subsequent code (the one behind the fun call, potentially > calling Release()) gets not executed before the function returns > even if the function body is preempted in the middle. > > Further, I guess it makes sense for the client/caller to have references > in thread local storage (private heap) or on the thread's stack (local > variable) wherever possible. > > A function does not > >> need to explictly AddRef() an |in| interface pointer. > > > > OK. Got it. > > >> >> Now this guarantee calls for all code to handle your |ifcPtr| >> "correctly". Basically, it means that no one can call delete() >> directly on this interface pointer. They may only use Release() to >> end the life time of an object. If the entire system obeys this rule, >> then there is no problem. > > > > Clear, don't bypass stuff. > >> >> Of course, there is a whole field of understand about reference count >> balancing and ownership. It is tricky to understand and harder to get >> right. (or maybe that is the other way around.) There are plenty of >> place in the mozilla source base which have sticky ownership problems. >> (do an LXR searce for "KungFoDeathGrip"). > > > > Puh. I will have a look into this. Guess cyclic ownerships are part > of this mantra, or is it zen or kungfo? It strangly reminds me of the > entity relationship complexities one can encounter in a model as soon as > one leaves the road of strict hierarchies. add physical and logical > chronologies and you're ready for the psychiatrist .. > > >> >> In general, if the system stick to only addref and release of xpcom >> objects, there is no problem. I have traced too many problem down >> where parts of a system treated an interface pointer with >> AddRef/Release, and other parts decided to call delete directly. This >> basically results in what you are talking about, in the middle of your >> function, |ifcPtr| suddenly becomes garbage. > > > > I promise to never bypass refcounting .. and i will eat my vegetables ;) > > >> >> Does this make sense? > > > > Thanks alot for clearifying. > > Tobias > >> >> Doug Turner >> [EMAIL PROTECTED] >> > >
