Bug 1223132 - Use thread-safe helper instead of UIImage(data: NSData)

[thebnich]

Note that we also do off-thread operations with UIImage in put:

         return deferDispatchAsync(queue) { () -> Success in
             let imagePath = (self.filesDir as NSString).stringByAppendingPathComponent(key)
             if let data = UIImageJPEGRepresentation(image, self.quality) {

It's unclear whether this is also unsafe, though moving it to the main thread would be pretty costly (IIRC, this operation took hundreds of milliseconds when I ran some benchmarks). I'm inclined to leave it as is for now until we have evidence that it's a problem.

[rnewman]

UIImage is safe to use on any thread. From the docs:

Image objects are immutable, so you cannot change their properties after
creation. This means that you generally specify an image’s properties at
initialization time or rely on the image’s metadata to provide the property
value. It also means that image objects are themselves safe to use from any
thread. The way you change the properties of an existing image object is to use
one of the available convenience methods to create a copy of the image but with
the custom value you want.

[rnewman]

This line is the only one that needs to be run on the main thread, so I think you should roll back the UIImage to NSData change and see if this still fixes the bug.

[thebnich]

Actually, we crash before this -- see line linked in bug. The crash happens on the UIImage(data) init.

[thebnich]

This might be an iOS bug -- after some research, I found the same issue reported in the HanekeSwift repo. If we want, we could use the solution from there (using a fine-grained lock around this initializer).

[rnewman]

If this fixes things, great.

I have a tiny glimmer of fear that it doesn't: CIImage, as far as I can tell, is pretty lazy; that might leave a gap for the same issue to occur. So please test thoroughly before landing!