Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Alex Zavatone]

On Oct 20, 2016, at 6:37 PM, Greg Parker wrote:

> 
>> On Oct 19, 2016, at 8:41 PM, Alex Zavatone  wrote:
>> 
>> In that case we would find out really quickly, because this is one of the 
>> classes that starts up as soon as the app makes several server calls.  When 
>> our error happens that appears like a dealloc, the app has been running and 
>> using this class for a while and is sitting around on iOS while it is in the 
>> background.
>> 
>> Yet we are seeing log output indicating the init method getting executed 
>> twice.  
> 
> Verify that you are seeing two init logs from one process rather than one 
> init log each from two processes. (Adding the PID to the log should resolve 
> that, if you don't have it already.)
> 
> Verify that your singleton enforcement is thread-safe. Thread-unsafe 
> singleton enforcement can create a second singleton if there is a race.
> 
> Log the stack trace of each init call. Perhaps one caller is bypassing your 
> singleton enforcement somehow. (For example, you wrote singleton enforcement 
> in +alloc but some call sites are using +allocWithZone:.)
> 
> Log the address of the object being returned by init. Perhaps there is only 
> one object but init is being called a second time on it.

That's a big one right there.  The address would be different if this was 
another instance.  

Thanks Greg, I'll make sure that we track this more closely to verify if this 
is or is not happening.

We did have one case months ago where the object was losing the reference to 
the singleton's static ref.  No idea how that happened, but directly calling 
the singleton through it's sharedReference solved the issue.  

Thanks.

> 
> Log or crash in dealloc, if your singleton enforcement might allow the object 
> to be deallocated and then a new one to be created.
> 
> 



___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Greg Parker]

> On Oct 19, 2016, at 8:41 PM, Alex Zavatone  wrote:
> 
> In that case we would find out really quickly, because this is one of the 
> classes that starts up as soon as the app makes several server calls.  When 
> our error happens that appears like a dealloc, the app has been running and 
> using this class for a while and is sitting around on iOS while it is in the 
> background.
> 
> Yet we are seeing log output indicating the init method getting executed 
> twice.  

Verify that you are seeing two init logs from one process rather than one init 
log each from two processes. (Adding the PID to the log should resolve that, if 
you don't have it already.)

Verify that your singleton enforcement is thread-safe. Thread-unsafe singleton 
enforcement can create a second singleton if there is a race.

Log the stack trace of each init call. Perhaps one caller is bypassing your 
singleton enforcement somehow. (For example, you wrote singleton enforcement in 
+alloc but some call sites are using +allocWithZone:.)

Log the address of the object being returned by init. Perhaps there is only one 
object but init is being called a second time on it.

Log or crash in dealloc, if your singleton enforcement might allow the object 
to be deallocated and then a new one to be created.


-- 
Greg Parker gpar...@apple.com   Runtime 
Wrangler


___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Alex Zavatone]

On Oct 19, 2016, at 4:04 PM, Doug Hill wrote:

> 
>> On Oct 19, 2016, at 2:00 PM, Jens Alfke  wrote:
>> 
>> 
>>> On Oct 19, 2016, at 1:23 PM, Steve Mills  wrote:
>>> 
>>> Pardon my obvious question, but this isn't a matter of your app napping 
>>> while in the background, is it? Or something like that?
>> 
>> Why would that cause a singleton to be dealloced? The app just stops getting 
>> CPU time for a while.
>> 
>> —Jens
> 
> Presumably if the app is terminated due to inactivity everything would be 
> dealloc'd including singletons. No idea if that is happening or not in this 
> case though.
> 
> Doug Hill

We have a repeating background task scheduled to operate when the app is within 
the background.
___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Jens Alfke]

> On Oct 19, 2016, at 8:41 PM, Alex Zavatone  wrote:
> 
> Yet we are seeing log output indicating the init method getting executed 
> twice.  

Set a breakpoint on it?
Or add a counter to the init method so it crashes on the second call, so you 
get a crash log with a backtrace?

—Jens
___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Alex Zavatone]

On Oct 19, 2016, at 3:03 PM, Jens Alfke wrote:

> 
>> On Oct 19, 2016, at 12:54 PM, Alex Zavatone  wrote:
>> 
>> Is there anything wrong with what I'm doing?  
> 
> Looks fine to me. Is any of this code using manual ref-counting? If so, I’d 
> suspect an over-release.

Thank god, no.  

> 
>> should I be using [GeofenceControllerSingleton alloc] init] instead of 
>> [[self alloc] init]?
> 
> It would be slightly safer since it guarantees the base class will be 
> instantiated (which is what you probably expect) instead of any subclass that 
> this factory method is called on.
> 

In that case we would find out really quickly, because this is one of the 
classes that starts up as soon as the app makes several server calls.  When our 
error happens that appears like a dealloc, the app has been running and using 
this class for a while and is sitting around on iOS while it is in the 
background.

Yet we are seeing log output indicating the init method getting executed twice. 
 

Thanks much guys.

> —Jens

___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Greg Parker]

> On Oct 19, 2016, at 2:29 PM, Steve Christensen  wrote:
> 
> The only difference between your code and mine is that you haven't 
> initialized onceToken = 0 so it has a random value.
> 
> I looked around to see if that makes a difference and didn't get much 
> confirmation one way or another. One by Mike Ash 
> (https://www.mikeash.com/pyblog/friday-qa-2014-06-06-secrets-of-dispatch_once.html)
>  mentions, "Note that dispatch_once_t is just a typedef for long, initialized 
> to zero, and with the meaning of other values left up to the implementation."

No difference. C static storage with no initializer is always initialized to 
zero.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Steve Christensen]

The only difference between your code and mine is that you haven't initialized 
onceToken = 0 so it has a random value.

I looked around to see if that makes a difference and didn't get much 
confirmation one way or another. One by Mike Ash 
(https://www.mikeash.com/pyblog/friday-qa-2014-06-06-secrets-of-dispatch_once.html)
 mentions, "Note that dispatch_once_t is just a typedef for long, initialized 
to zero, and with the meaning of other values left up to the implementation."

It's a simple thing to change to see what happens.


> On Oct 19, 2016, at 12:54 PM, Alex Zavatone  wrote:
> 
> On Oct 19, 2016, at 2:08 PM, Steve Christensen wrote:
> 
>> This is the model I use for singletons and I've never had the singleton 
>> instance deallocated out from under me.
>> 
>> + (MyClass*) sharedThing
>> {
>>  static dispatch_once_t sOnceToken = 0;
>>  static MyClass* sSharedThing = nil;
>> 
>>  dispatch_once(,
>>  ^{
>>  sSharedThing = [[MyClass alloc] init];
>>  });
>> 
>>  return sSharedThing;
>> }
>> 
> 
> It appears that this is what I am doing.  Though the details are not the 
> same, should this matter?
> 
> We have already had to patch one instance where the ref to this was getting 
> lost 
> 
> + (instancetype)referenceGeofenceController {
>   static GeofenceControllerSingleton *geofenceController;
>   static dispatch_once_t onceToken;
> 
>   dispatch_once(, ^{
>   geofenceController = [[self alloc] init];
>   });
>   return geofenceController;
> }
> 
> 
> Is there anything wrong with what I'm doing?  should I be using 
> [GeofenceControllerSingleton alloc] init] instead of [[self alloc] init]?
> 
> Thanks a million.  
> Alex Zavatone
> 
>>> On Oct 19, 2016, at 11:41 AM, Alex Zavatone  wrote:
>>> 
>>> We are running into what appears to be a case where a singleton that has 
>>> been created through GCD dispatch_once may be getting deallocated by the OS.
>>> 
>>> To check and see if this is the case, I have put logging code in the 
>>> dealloc method, but our logs do show the init method being called twice 
>>> even though the method is past the dispatch_once.
>>> 
>>> I'm interested in seeing if I can prevent the singleton from being 
>>> deallocated.
>>> 
>>> I have seen on discussion where people suggest keeping a private strong 
>>> property in the singleton with a reference to self to prevent this from 
>>> happening.
>>> 
>>> Something like 
>>>  self.selfReference = self;
>>> 
>>> within an interface extension.
>>> 
>>> Naturally, this is raising some eyebrows with other members of the team, 
>>> but currently, no one has a solution to make sure that this core singleton 
>>> doesn't get deallocated when the app is in the background and has been 
>>> running for a while.
>>> 
>>> Does this sound sane or a horrible idea?
>>> 
>>> If it does sound like a horrible idea, how would you suggest preventing an 
>>> important singleton from being deallocated?
>>> 
>>> Thanks in advance,
>>> Alex Zavatone


___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Jonathan Mitchell]

> On 19 Oct 2016, at 22:14, Jens Alfke  wrote:

>  So that’s not what the problem is.
> 
It may be that the a separate instance of the singleton is getting created via 
the normal alloc - init sequence outside of the normal singleton accessor.
That should be trivial to check for.
___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Jens Alfke]

> On Oct 19, 2016, at 2:14 PM, Jens Alfke  wrote:
> 
> No, nothing would be dealloced. The whole process would just be killed

Sorry, I misspoke — I got it mixed up with termination for using too much 
memory.

If the app gets quit in the background it does get notified that it’s quitting 
and can clean up. But the singleton isn’t going to be dealloced. Not unless the 
Obj-C runtime has an on-termination task that nils out static strong object 
references, which seems like a silly thing to do because all it does is delay 
the process’s exit.

(C++ static destructors _do_ run on termination, but generally one tries to 
avoid having those, because they’re usually useless. There’s even a compiler 
warning for them.)

—Jens

___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Doug Hill]

> On Oct 19, 2016, at 2:14 PM, Jens Alfke  wrote:
> 
> 
>> On Oct 19, 2016, at 2:04 PM, Doug Hill > > wrote:
>> 
>> Presumably if the app is terminated due to inactivity everything would be 
>> dealloc'd including singletons. No idea if that is happening or not in this 
>> case though.
> 
> No, nothing would be dealloced. The whole process would just be killed, and 
> _nothing_ would happen in it after that point, including seeing a null 
> singleton pointer. So that’s not what the problem is.
> 
> —Jens



FWIW, in the past I saw my iOS shut down gracefully when being terminated due 
to inactivity or low-memory, rather than just a kill -9. I haven't checked this 
lately though.

Doug Hill
___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Jens Alfke]

> On Oct 19, 2016, at 2:04 PM, Doug Hill  wrote:
> 
> Presumably if the app is terminated due to inactivity everything would be 
> dealloc'd including singletons. No idea if that is happening or not in this 
> case though.

No, nothing would be dealloced. The whole process would just be killed, and 
_nothing_ would happen in it after that point, including seeing a null 
singleton pointer. So that’s not what the problem is.

—Jens
___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Doug Hill]

> On Oct 19, 2016, at 2:00 PM, Jens Alfke  wrote:
> 
> 
>> On Oct 19, 2016, at 1:23 PM, Steve Mills  wrote:
>> 
>> Pardon my obvious question, but this isn't a matter of your app napping 
>> while in the background, is it? Or something like that?
> 
> Why would that cause a singleton to be dealloced? The app just stops getting 
> CPU time for a while.
> 
> —Jens

Presumably if the app is terminated due to inactivity everything would be 
dealloc'd including singletons. No idea if that is happening or not in this 
case though.

Doug Hill


___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Jens Alfke]

> On Oct 19, 2016, at 1:23 PM, Steve Mills  wrote:
> 
> Pardon my obvious question, but this isn't a matter of your app napping while 
> in the background, is it? Or something like that?

Why would that cause a singleton to be dealloced? The app just stops getting 
CPU time for a while.

—Jens
___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Steve Mills]

Pardon my obvious question, but this isn't a matter of your app napping while 
in the background, is it? Or something like that?

Steve via iPhone


___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Jens Alfke]

> On Oct 19, 2016, at 12:54 PM, Alex Zavatone  wrote:
> 
> Is there anything wrong with what I'm doing?  

Looks fine to me. Is any of this code using manual ref-counting? If so, I’d 
suspect an over-release.

> should I be using [GeofenceControllerSingleton alloc] init] instead of [[self 
> alloc] init]?

It would be slightly safer since it guarantees the base class will be 
instantiated (which is what you probably expect) instead of any subclass that 
this factory method is called on.

—Jens
___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Alex Zavatone]

On Oct 19, 2016, at 2:08 PM, Steve Christensen wrote:

> This is the model I use for singletons and I've never had the singleton 
> instance deallocated out from under me.
> 
> + (MyClass*) sharedThing
> {
>   static dispatch_once_t sOnceToken = 0;
>   static MyClass* sSharedThing = nil;
> 
>   dispatch_once(,
>   ^{
>   sSharedThing = [[MyClass alloc] init];
>   });
> 
>   return sSharedThing;
> }
> 

It appears that this is what I am doing.  Though the details are not the same, 
should this matter?

We have already had to patch one instance where the ref to this was getting 
lost 

+ (instancetype)referenceGeofenceController {
   static GeofenceControllerSingleton *geofenceController;
   static dispatch_once_t onceToken;

   dispatch_once(, ^{
   geofenceController = [[self alloc] init];
   });
   return geofenceController;
}


Is there anything wrong with what I'm doing?  should I be using 
[GeofenceControllerSingleton alloc] init] instead of [[self alloc] init]?

Thanks a million.  
Alex Zavatone

> 
> 
>> On Oct 19, 2016, at 11:41 AM, Alex Zavatone  wrote:
>> 
>> We are running into what appears to be a case where a singleton that has 
>> been created through GCD dispatch_once may be getting deallocated by the OS.
>> 
>> To check and see if this is the case, I have put logging code in the dealloc 
>> method, but our logs do show the init method being called twice even though 
>> the method is past the dispatch_once.
>> 
>> I'm interested in seeing if I can prevent the singleton from being 
>> deallocated.
>> 
>> I have seen on discussion where people suggest keeping a private strong 
>> property in the singleton with a reference to self to prevent this from 
>> happening.
>> 
>> Something like 
>>   self.selfReference = self;
>> 
>> within an interface extension.
>> 
>> Naturally, this is raising some eyebrows with other members of the team, but 
>> currently, no one has a solution to make sure that this core singleton 
>> doesn't get deallocated when the app is in the background and has been 
>> running for a while.
>> 
>> Does this sound sane or a horrible idea?
>> 
>> If it does sound like a horrible idea, how would you suggest preventing an 
>> important singleton from being deallocated?
>> 
>> Thanks in advance,
>> Alex Zavatone
> 


___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Jens Alfke]

> On Oct 19, 2016, at 11:41 AM, Alex Zavatone  wrote:
> 
> I have seen on discussion where people suggest keeping a private strong 
> property in the singleton with a reference to self to prevent this from 
> happening.

Bad idea: it relies on the implementation detail that the runtime can’t detect 
reference cycles. It would fail in the (obsolete) garbage collected 
environment, and it could fail in the future if Apple extends the Obj-C runtime 
to be able to detect unreachable reference cycles and collect them.

(Also, even in the present day it will trigger the leak detectors in 
Instruments and in Xcode 8’s new memory visualizer.)

If you want something to stick around forever, make a static variable that 
points to it (as in Steve’s example.)

—Jens
___

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

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Steve Christensen]

This is the model I use for singletons and I've never had the singleton 
instance deallocated out from under me.

+ (MyClass*) sharedThing
{
static dispatch_once_t sOnceToken = 0;
static MyClass* sSharedThing = nil;

dispatch_once(,
^{
sSharedThing = [[MyClass alloc] init];
});

return sSharedThing;
}



> On Oct 19, 2016, at 11:41 AM, Alex Zavatone  wrote:
> 
> We are running into what appears to be a case where a singleton that has been 
> created through GCD dispatch_once may be getting deallocated by the OS.
> 
> To check and see if this is the case, I have put logging code in the dealloc 
> method, but our logs do show the init method being called twice even though 
> the method is past the dispatch_once.
> 
> I'm interested in seeing if I can prevent the singleton from being 
> deallocated.
> 
> I have seen on discussion where people suggest keeping a private strong 
> property in the singleton with a reference to self to prevent this from 
> happening.
> 
> Something like 
>self.selfReference = self;
> 
> within an interface extension.
> 
> Naturally, this is raising some eyebrows with other members of the team, but 
> currently, no one has a solution to make sure that this core singleton 
> doesn't get deallocated when the app is in the background and has been 
> running for a while.
> 
> Does this sound sane or a horrible idea?
> 
> If it does sound like a horrible idea, how would you suggest preventing an 
> important singleton from being deallocated?
> 
> Thanks in advance,
> Alex Zavatone


___

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

iOS: Preventing a singleton from being deallocated when the app is in the background.

[Alex Zavatone]

We are running into what appears to be a case where a singleton that has been 
created through GCD dispatch_once may be getting deallocated by the OS.

To check and see if this is the case, I have put logging code in the dealloc 
method, but our logs do show the init method being called twice even though the 
method is past the dispatch_once.

I'm interested in seeing if I can prevent the singleton from being deallocated.

I have seen on discussion where people suggest keeping a private strong 
property in the singleton with a reference to self to prevent this from 
happening.

Something like 
self.selfReference = self;

within an interface extension.

Naturally, this is raising some eyebrows with other members of the team, but 
currently, no one has a solution to make sure that this core singleton doesn't 
get deallocated when the app is in the background and has been running for a 
while.

Does this sound sane or a horrible idea?

If it does sound like a horrible idea, how would you suggest preventing an 
important singleton from being deallocated?

Thanks in advance,
Alex Zavatone
___

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