On Thursday, July 11, 2002, at 02:05 PM, Joseph J. Strout wrote:
At 12:03 PM -0700 7/11/02, Brady Duga wrote:
And in fact, as you've described it, the Tickled object won't go away
at all. The Tickler still has a reference to it, so until the
Tickler object dies (which presumably won't be until the app exits),
anything it has a reference to will stay alive too.
I assume the Tickler would go away when its ref count dropped to 0.
Yes. And that will be when the app quits, right? You must have some
global reference to it; how does the Timer tell it to do its thing?
Nope - that's precisely what I'm trying to avoid! Of course, in my
real-world case, the Tickled object has references to other objects,
but no back references. Specifically, the Tickled object has an array of
objects that it treats as a stack - every second it tells the object at
the end of the array to do something - when it runs out of items, it
dies. The only reference to the tickled is from the tickler. The only
reference to the tickler is from the tickled. They both survive only due
to the others existence - when one of them passes away, so goes the
other!
I'm not sure I explained this correctly.
I think you did.
In that call, it sets the mTickler reference to nil if IAmDone()
returns true, leaving:
0 1
mTickler ----> mTickeled
Doesn't this cause mTickler to vanish?
Only if you have no other references to the Tickler object, which I
find hard to believe.
Which is precisely what I have. A co-dependent pair that no one else is
aware of, nor do they need to be. Question is, when one of them passes
away while the other is talking to it, will I have problems?
--Brady
The La Jolla Underground
|