Re: [iosdev] Re: a deduping version of dispatch_async

[Vaddadi Kartick (please call me Kartick)]

First, let me describe how our Java code handles interruption:

- To interrupt a thread you call Thread.interrupt().

- If, at that time, the thread is sleeping, doing I/O, or waiting on a mutex, an InterruptedException is thrown.

- Otherwise, it just sets a flag for that thread. The code running in the thread needs to check for that flag:

    if (Thread.currentThread().isInterrupted()) {
      throw new InterruptedException();
    }

It should check regularly, before and after any time-consuming operation, and once per iteration.

- Well-written Java code ensures that files are closed and other resources are released when an exception occurs.

- Any catch blocks that catch Exception or Throwable (as opposed to a specific exception class like SQLException) need to check if the caught exception was an InterruptedException and if so, rethrow it.

- Eventually the InterruptedException exits the run() method of the thread, causing the thread to terminate.

Now, I can see two differences wrt iOS:

- Memory management: I assume J2Objc and/or Clang ensures that refcounts are properly updated when an exception happens. It should, to correctly implement Java semantics, which is that memory is reclaimed if you have an exception. If not, we have a memory leak independent of interruption.

- When invoking J2Objc code from within GCD, GCD may catch the exception and ignore it, or it may let the exception propagate, letting the thread terminate, and create a new thread to run the next block. It doesn't matter. That's an implementation detail of GCD.

Anything I'm missing?

[Josh Osborne]

Apple infrequently uses exception in public interfaces in ObjC to indicate anything other then a severe non-recovrable state.   They do use it internally to libraries for recoverable conditions (Core Data uses it when multiple threads modify the same NSManagedObject and it has to figure out what to do about it, and I want to say a badly misconfigured NSCollectionViewLayout can manage to trigger it, but that is borderline anyway, I'm sure other places exist).   So I wouldn't expect any outright crashes, but I wouldn't really trust it very far.   At the very least test it a lot, and if something breaks don't rule out the compiler, the runtime, or Apple's frameworks.

[George Kola]

Please, not that by default ARC may leak memory when exceptions are thrown. There were two cases  (1. Core data bug causing rare exception  2. A bug in Apple image handling for a very low fraction of images generated on android) where we made the app recover from exceptions and had to enable -fobjc-arc-exceptions to not leak memory.

From the document

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions

By default in Objective C, ARC is not exception-safe for normal releases:

• It does not end the lifetime of __strong variables when their scopes are abnormally terminated by an exception.
• It does not perform releases which would occur at the end of a full-expression if that full-expression throws an exception.

A program may be compiled with the option -fobjc-arc-exceptions in order to enable these, or with the option -fno-objc-arc-exceptions to explicitly disable them, with the last such argument “winning”.

Rationale

The standard Cocoa convention is that exceptions signal programmer error and are not intended to be recovered from. Making code exceptions-safe by default would impose severe runtime and code size penalties on code that typically does not actually care about exceptions safety. Therefore, ARC-generated code leaks by default on exceptions, which is just fine if the process is going to be immediately terminated anyway. Programs which do care about recovering from exceptions should enable the option.

Cheers,
George

[Vaddadi Kartick (please call me Kartick)]

George,

Thanks for that. I'd come across that, but since our code uses Objective-C++ we're good.

Josh, thanks, I'll keep that in mind.

My main point was that since exceptions are common in Java, the interruption system shouldn't cause any issues that don't otherwise exist.

[Vaddadi Kartick (please call me Kartick)]

We're fixing these in http://cr/118349580 and http://cr/118341496 . Please let us know if you still see any race conditions or can think of other tests to write.