Destroying self from within self

Question

I have an Objective-C class whose instances can detect when they are no longer needed and destroy themselves, but I am looking for a safe way to trigger an object's self-destruction from within the object itself, without somehow "destroying the method that is calling the destruction"... My code looks roughly like this (some removed for brevity):

+ (oneway void)destroyInstance:(id)obj {

    printf("Destroying.\n");
    if (obj != nil) {
        free(obj);
        obj = nil;
    }

}

- (oneway void)release {

    _noLongerRequired = [self determineIfNeeded]; // BOOL retVal

    if (_noLongerRequired) {
        [self deallocateMemory]; // Free ivars etc (NOT oneway)
        [MyClass destroyInstance:self]; // Oneway
    }
}

If I call -release, it should return instantly to the main thread (due to the oneway).

Meanwhile, if the instance finds it is no longer needed, it should then call the oneway class method destroyInstance: and remove itself from the runtime. My question is, is this safe?? And have I used oneway correctly? It seems to me there is the possibility of destroying the instance's -release function before it returns, which could be... rather bad..?

(PS: Obviously not looking for anything to do with NSObject, etc :))

Agree, this sounds like a bad idea. What is the problem with letting ARC do the work? if you have additional cleaning you can put it in dealloc. I fail to see the use case for your problem. If you are doing something crazy with the runtime and not using ARC or GC, use objc_disposeClassPair, but do it from another object. — Jano, Oct 14 '12 at 11:44
@Jano ARC won't handle (I assume?) anything not inheriting from NSObject, I'm trying to make my own base class and looking for a reasonable destruction mechanism - offloading to another object is looking quite good at the moment! — Ephemera, Oct 15 '12 at 00:45
ARC handles any object or block pointer. See http://clang.llvm.org/docs/AutomaticReferenceCounting.html#objects This may interest you too: http://www.mikeash.com/pyblog/friday-qa-2011-09-16-lets-build-reference-counting.html — Jano, Oct 15 '12 at 02:50
@Jano Cheers! That's exactly the sort of thing I need to look into! I wasn't aware that ARC was quite so general either... — Ephemera, Oct 15 '12 at 09:49

Carl Veazey · Accepted Answer · 2012-10-14T22:36:48.650

This is without a doubt a terrible idea if you want working and maintainable software and unsafe in just about any context. But sometimes terrible, unsafe ideas can be fun on the weekend, so I'll answer the components of the question I can discern.

A method will not get "destroyed" because an instance is deallocated. What can happen is that self can end up pointing to deallocated memory during the execution of a method, which means that accessing self or any instance variables during this time can crash.

As to the rest of your code, there is no reason at all to set obj equal to nil in +destroyInstance, so if you were trying accomplish something in particular (nil'ing out pointers to the object perhaps) that way is not the right way to go about it.

Thinking about the use of oneway, what the language says is that sending this message won't block the calling thread. In the context of releasing objects I think it makes some sense, as presumably the target of the message won't ever be referenced by that thread again. By that logic I'd think your declaration of +destroyInstance is maybe OK. I do wonder if you'd need to provide some sort of synchronization so that there's no retain/release race conditions but thinking about it, taking ownership of an object should probably never be asynchronous.

My personal opinion is that anyone who puts this code into production should probably be fired or sued =P. But if it's only for educational purposes, have fun, and hope this helps.

Haha don't worry, it's definitely only educational - I'm trying my hand at implementing my own NSObject. — Ephemera, Oct 15 '12 at 00:44

Destroying self from within self

1 Answers1