I’ve been read this thread with interest, I think you are over-complicating
things, unless I missed something.
Look at the following pseudo code:
// Create a New Payload Object
LTWPayloadItem* myPayloadItem; //An object that contains
references to other objects
NSString* myItemID;
myItemID = @“ID-001”;
myPayloadItem = [[LTWPayloadItem alloc] initWithSomeParameters:xxxxxx];
[self.pPayloadDictionary setObject: myPayloadItem forKey: myItemID];
[myPayloadItem release];
// At this point, myPayloadItem has a retain count of 1
So if you remove it from the dictionary (which is what you want to do under
when under memory pressure):
[self.pPayloadDictionary removeObjectForKey: myItemID];
It will be dealloc’ed.
If another part of the application wants to access Item “ID-001”, then if they
always access it like this:
myPayloadObject = [self.pPayloadDictionary ObjectForKey: @“ID-001"];
[myPayloadObject retain]; //Retain count of 2
Now if Item “ID-001” get removed from the dictionary, it will not be
dealloc’ed, but it will be removed from the dictionary.
When the code has finished accessing the item “ID-001”, it executes:
[myPayloadObject release]; //Retain count of 1
Now if Item “ID-001” get removed from the dictionary, it will also be
dealloc’ed.
Isn’t this what you want to achieve?
Of course this would be implemented as a Global Manager Class which is called
from other parts of the application, something like this:
-(void) addItemID:(NSString*) theID withPayloadItem:(LTWPayloadItem*)
thePayloadItem
{
@synchronized (self.pPayloadDictionary)
{
[self.pPayloadDictionary setObject: thePayloadItem forKey:theID];
}
}
-(void) removeItemID:(NSString*) theID
{
@synchronized (self.pPayloadDictionary)
{
[self.pPayloadDictionary removeObjectForKey:theID];
}
}
-(void) addItemID:(NSString* theID withPayloadItem:(LTWPayloadItem*)
thePayloadItem
{
@synchronized (self.pPayloadDictionary)
{
[self.pPayloadDictionary setObject: thePayloadItem forKey:theID];
}
}
-(LTWPayloadItem*) newAccessWithID:(NSString* theID
{
LTWPayloadItem* myPayloadItem;
@synchronized (self.pPayloadDictionary)
{
myPayloadItem = [self.pPayloadDictionary objectForKey:theID];
}
[myPayloadItem retain];
return myPayloadItem;
}
-(void) releaseAccessWithPayload:(LTWPayloadItem*) thePayloadItem
{
[thePayloadItem release];
}
All the Best
Dave
> On 18 May 2015, at 01:47, Britt Durbrow
> <bdurb...@rattlesnakehillsoftworks.com> wrote:
>
> Ughh… I find myself in a bit of a quandary:
>
> I have a pool of disk-backed (well, flash-backed on iOS) objects that have an
> arbitrary graph structure. These are managed by a central object pool. The
> object pool is supposed to cache these in memory (creating them is somewhat
> non-trivial), and hold onto ones that it’s been told to even if there are no
> other objects that currently have an active pointer to them outside of the
> pool’s object graph (consequently, just using weak links won’t work for my
> problem).
>
> In order to respond to iOS memory pressure warnings, I need to have the
> object pool de-construct and release any graph segments that are not
> currently being used outside of the object pool. However, this needs to
> happen only during a memory pressure event, and not otherwise.
>
> The only thing I’ve been able to come up with so far is somehow tracking the
> retain count state of the objects in the object pool, and when a memory
> pressure event occurs having the object pool find all the objects that are
> only in use in the graph and held by itself, and release them. Once all the
> otherwise unused objects have been converted via an isa swizzle to faults
> (and thusly no longer contain retain cycles), the faulted objects that are
> candidates for release should have a retain count of 1… at which point I can
> have the pool remove them from it’s main NSMutableDictionary (which will now
> cause them to be deallocated).
>
> This, however, is kinda ugly… and known to be prone to pitfalls... but is
> there any better way?
>
> Note that I don’t want to just use CoreData. Also, I did think of having the
> objects in the graph that are supposed to be held on to be held in a strong
> container, and the objects not currently being held on to in a weak
> container, but that doesn’t work because then the objects in the weak
> container will get purged when immediately, not just under a memory pressure
> event.
>
>
> So what I’m looking at now is creating an intermediate base class for all of
> these objects, that is compiled with ARC turned off, and provides access to
> retainCount. Yes, I know that it doesn’t reflect any autoreleases that have
> occurred on the object. This is OK as far as I know - for this specific use,
> if something has an outstanding autorelease on an object, it’s probably OK to
> keep it around, as long as enough of the cached objects get purged to satisfy
> the memory pressure event. Also, this object pool is not guaranteed to be
> thread-safe so I don’t think that the potential race conditions of
> retain/release/autorelease/retainCount interaction will come into play.
>
>
> Any ideas? Comments? Rotten tomatoes? :-)
> _______________________________________________
>
> 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/dave%40looktowindward.com
>
> This email sent to d...@looktowindward.com
_______________________________________________
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
