I don’t wish to butt in, since you seem to be doing fine and I probably don’t have too much to contribute, but just pointing you at NSDiscardableContent for a second, that has a “pseudo-retain count” type of mechanism that is independent of the actual retain count.
I wonder if that couldn’t help you here - leave the standard retain count to its own devices, and use the access count of NSDiscardableContent to manage your object in these higher-level terms. It requires a little bit of cooperation from all other code that will access your objects, but it makes it a lot saner than trying to reason about retain counts themselves (which I agree with is the path to madness). Since nothing else will be manipulating the access count other than code you write, you can reason about that all day long. —Graham > On 19 May 2015, at 10:14 am, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On May 18, 2015, at 16:25 , Britt Durbrow > <bdurb...@rattlesnakehillsoftworks.com> wrote: >> >> If some objects are in autorelease pools, that means that there is a strong >> link to them out there somewhere (presumably on the stack or in a register >> where it’s going to go away once the stack frames get popped) and the object >> pool controller shouldn’t let go of the object yet. Hopefully there will be >> enough else that can be released that the memory pressure gets satisfied. >> Also, I can set a flag to cause the object pool controller to re-scan the >> pool for objects to release after the main autorelease pool is drained in >> the main event loop. > > But here we go, reasoning about retain counts — incorrectly. (Your first > sentence is just false, BTW, not incorrectly reasoned. An object can be in an > autorelease pool with no other strong link anywhere.) And you’ve got me doing > it too. What I said previously about retain counts of objects in autorelease > pools was just wrong. > >> why I can’t have the object pool controller just drop an object unless the >> pool controller is the only one with a strong link to the object. > > Because what you really want is “unless the pool controller is the only one > with an accessible link to the object”. You’re trying hard to force “strong > link” to do the duty of “accessible link”, and I’m trying hard to tell you > that it can’t. > > Also, I’m not trying to steer you towards the double pointer approach. > Paradoxical as it may seem, I’m suggesting you can avoid that by merely > incrementing the retain count of objects you *know* to be accessible, and to > decrement it when you *know* they become inaccessible. You can reason about > *that* retain count (“it keeps objects alive when present”). You just can’t > validly reason about anyone else’s retain counts. :) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
