On 19 May 2015, at 17:52, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com
wrote:
Yes, I am a bit concerned that it could become deprecated. I suppose that I
could just override retain and release in that case; and track the retain
count myself; although I seriously doubt that that
On 20 May 2015, at 2:17 pm, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
My answer on this to Britt is that this is unknowable in general. *That* (or
so I claim) is why it’s not safe to reason about retain counts. If Britt
could be said to be wrong about anything, I’d say
On May 19, 2015, at 8:04 PM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
Solution B: We retain each object as it enters the cache. That allows us to
selectively mark objects purgeable by releasing them again. Drawbacks: None.
You still have to be really careful about
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
In no particular order:
On May 19, 2015, at 8:37 PM, Graham Cox graham@bigpond.com wrote:
I think what the OP says he wants is that the cache can only release when it
knows nobody else has a reference to an object as well, hence the temptation
to peek at the retain count. In other
On 20 May 2015, at 20:00, Dave d...@looktowindward.com wrote:
I’ve been read this thread with interest, I think you are over-complicating
things, unless I missed something.
….
Isn’t this what you want to achieve?
No that’s not what he wants to achieve. He wants
1) When he needs an
On May 20, 2015, at 3:41 AM, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
On May 19, 2015, at 8:37 PM, Graham Cox graham@bigpond.com
mailto:graham@bigpond.com wrote:
I think what the OP says he wants is that the cache can only release when it
knows nobody else has
On May 20, 2015, at 01:41 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
A memory pressure event occurs, and OPC decides to evict DMO1, but it doesn’t
immediately go away, because VC1 is holding on to it.
VC2 comes along and wants to get at the object with UUID 12345 (in
On May 20, 2015, at 10:32 AM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
Turns out they weren’t so much off track as you need a smack upside the head.
[Er, wait, you’re a big dude with a beard, so perhaps kittens instead? You
like kittens? I don’t want to get hurt.]
On 21 May 2015, at 10:38 am, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
Also, generally speaking, I don’t want to have to go back to a manual
retain/release model for the whole app (which is basically what using
NSDiscardableContent entails; even though it isn’t literal
On May 20, 2015, at 17:38 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
We are, in fact, on the same page at this point!
Yes, I think so too. But you’ve thereby done yourself out of the kittens.
___
Cocoa-dev mailing list
On May 18, 2015, at 8:59 PM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
Let me try and summarize where we are, in response to the several recent
suggestions:
Close, but not quite:
I have several apps which are built on an existing, fully functional data
management
On May 19, 2015, at 20:37 , Graham Cox graham@bigpond.com wrote:
I think what the OP says he wants is that the cache can only release when it
knows nobody else has a reference to an object as well
My answer on this to Britt is that this is unknowable in general. *That* (or so
I claim)
On 20 May 2015, at 1:04 pm, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
I don’t think you’ve misunderstood anything at all.
Kind of you to say so - I’m not so sure :)
So, we look at two possible solutions. [Spoiler: Both solutions are 100%
correct, because both
On May 19, 2015, at 15:50 , Graham Cox graham@bigpond.com wrote:
I may have misunderstood the problem such that this is a poor ot for other
reasons, but I’m not seeing it. I’m also not sure why there seems to be a
tacit resistance to it - seems logical to me.
I don’t think you’ve
I just finished catching up on the discussion and keep coming back to the
fragile nature of relying on retainCount. For now you do, indeed, have the
option to vaporize your toes; later you may not have access to a ray gun if
Apple decides that it's in the best interests of all concerned that
On May 19, 2015, at 8:52 AM, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
On May 19, 2015, at 7:20 AM, Steve Christensen puns...@mac.com wrote:
I just finished catching up on the discussion and keep coming back to the
fragile nature of relying on retainCount. For now you do,
On 20 May 2015, at 12:20 am, Steve Christensen puns...@mac.com wrote:
One thought I had was to base all your cacheable objects on a class whose
sole function is to notify the cache when the last reference goes away, i.e.,
when dealloc is called
This is what NSDiscardableContent is able
On May 19, 2015, at 7:20 AM, Steve Christensen puns...@mac.com wrote:
I just finished catching up on the discussion and keep coming back to the
fragile nature of relying on retainCount. For now you do, indeed, have the
option to vaporize your toes; later you may not have access to a ray
On May 17, 2015, at 23:59 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
My understanding of retainCount is that it’s basically considered “taboo”
because trying to use it without knowing exactly what you are doing tends to
lead to pitfalls, and most people looking at it tend
On May 18, 2015, at 1:11 AM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On May 17, 2015, at 23:59 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
My understanding of retainCount is that it’s basically considered “taboo”
because trying to use it without
On May 18, 2015, at 10:52 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
Is the reasoning that:
1: Not under ARC;
2: There is one known strong link to an object;
3: retainCount returned 1
Therefore, the only strong link to the object is the known strong link
specified
On May 18, 2015, at 12:52 PM, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
In order to maintain graph coherency the object pool controller must ensure
that there is only ever one object in memory with a particular UUID.
Consequently, I can’t just have the object pool
I'm going to butt in here and say that if you've got so many objects that it is
causing memory pressure, you really just need to reevaluate and blow up your
model.
Consider using a database or Core Data.
Tracking and storing large relational sets of data is exactly what those things
do well.
Let me try and summarize where we are, in response to the several recent
suggestions:
Britt has an app with an existing, fully functional custom cache of objects
that have a UUID property, with the restriction that UUIDs are unique amongst
objects in the cache. Objects may be created in
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
On 18 May 2015, at 14:59, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
Unfortunately I don’t think NSCache will work for me in this situation.
The objects in the pool have a UUID that is used to maintain the graph
structure’s coherency when it’s partially or entirely on
On May 18, 2015, at 11:38 AM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On May 18, 2015, at 10:52 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
Is the reasoning that:
1: Not under ARC;
2: There is one known strong link to an object;
3: retainCount
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
Unfortunately I don’t think NSCache will work for me in this situation.
The objects in the pool have a UUID that is used to maintain the graph
structure’s coherency when it’s partially or entirely on disk. In RAM, there
can be only one object per UUID; but if something points to an object that
, 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
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
On May 17, 2015, at 17:47 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
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
On May 17, 2015, at 18:10 , Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
I think you are on the right track with this, but instead of partitioning the
objects into two containers, put all the objects in one container.
Er, I meant “put all the objects in both containers”.
On 18 May 2015, at 11:14 am, Jonathan Hull jh...@gbis.com wrote:
Instead of having a central object pool, have the objects adhere to a
protocol which takes a method to be called in low-memory situations
Yep. You could call it ‘NSDiscardableContent’ ;)
—Graham
Haha. Awesome! I didn’t even know this existed… thanks for the tip :-)
On May 17, 2015, at 6:30 PM, Graham Cox graham@bigpond.com wrote:
On 18 May 2015, at 11:14 am, Jonathan Hull jh...@gbis.com wrote:
Instead of having a central object pool, have the objects adhere to a
protocol
36 matches
Mail list logo
