Re: upper limit on retain count
Re: upper limit on retain count
- Subject: Re: upper limit on retain count
- From: Ali Ozer <email@hidden>
- Date: Tue, 19 Apr 2005 09:46:07 -0700
We don't document an upper bound, but we try to provide reasonable
upper bounds. If the upper bound is reached, we clamp. So objects
that are too popular may end up getting stuck around.
In practice most objects have 32 bits of retain count, although some
of the more popular ones (NSString, NSNumber, etc) will go higher
("millions of millions"). However, that should be regarded as an
implementation detail that can change.
If you really need retain counts >2^32 on your custom objects, you
can override retain, release, and retainCount to provide custom
referencing counting. Typically these would be overridden for
performance (for objects that are very frequently retained or
released), but managing higher retain counts is another reason...
Remember to make your implementations thread safe, if needed.
Note that your retainCount would not be able to report reference
counts higher than UINT_MAX; however, this doesn't mean you can't
have higher retain counts internally.
Ali
Begin forwarded message:
From: "Ivan S. Kourtev" <email@hidden>
Date: April 18, 2005 13:43:59 PDT
To: email@hidden
Subject: upper limit on retain count
Hello,
I wasn't able to find any documented upper limits on retain count
on 32-bit machines (or in general). I am interested in knowing
this because I foresee a situation where I may have objects with
retain counts of hundreds of millions of billions and more. So the
two questions I have are:
(1) is there a documented limit to the retain count?
(2) is there a documented behavior once the retain count max is
reached?
Thanks,
--
ivan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden