asarazan's comments

Does this mean we have to get rid of Speechless at Google IO?

I'm really hoping somebody at Oculus/HTC/Microsoft sees this and wants to develop it, because I agree the hardware industry needs to step up its game to make this a reality.

Android Lead from Capital One SF here. I did and it was one of the best hires I ever made. He's the most enthusiastic and motivated person on my entire team, and is also amazing at UI and performance optimization. I've been begging them to send me more candidates ever since.

Did this get killed? I can't find it on the list

I failed pretty hard. 1/5

If "most cases" means the average small team (2-3 developers), then you probably have a point. Once you have more than that, I think it's absolutely necessary to enforce code style in this way.

Thanks for reading the article so thoroughly.

Yeah this is the general idea we went with. We did our best to synchronize around it, but unfortunately we can never have total control, which necessarily introduces race conditions.

I would imagine this is what leads to the 0.4% crash rate I mentioned at the top of the article :-(

I was going for more of a sly joke with the title, but it appears to have not gone over well. I now regret my decision.

I agree. Would be nice to stop having to worry about this crap at every turn when developing on iOS.

We do this for various other reasons (clearing possibly corrupted state, etc), but we've never uploaded the statistics to the servers. We may begin doing this in the future.

We've been using Crittercism in the past and recently switched to Crashlytics, unfortunately memory crashes are one of the few exceptions (hah) to the rule, as they are SIGKILLs from the OS.

Another commenter recommended touching a file at launch and at sleep to track untraceable crashes, which we do for various other reasons, but don't upload the stats. We may begin doing this.

I won't argue too strongly on this, as you're far more knowledgable about it than I am.

However, imo the intention and semantics behind a call like CFMakeCollectable implies a transfer of ownership to an external system. A newbie Apple coder could be forgiven for thinking it would still transfer ownership in RC environments, just to the autorelease pool instead of a collector. In all likelihood this is what happened. An intern got at the code and didn't know the details about GC.

Obviously the point stands that this interpretation is well-documented to be false, but its naming is definitely misleading.

Double edit: I see from your edit that some of my basic assumptions about CFMakeCollectable were wrong, having never actually worked with it. My bad.

I would disagree pretty strongly with that. The function CFMakeCollectable is explicitly a function for dealing with the garbage collector, and its unpredictability in non-garbage-collected code is the direct cause of the bug.

Doesn't it make sense to say that without the existence of Apple GC, the bug never would have existed? Doesn't that at least somewhat justify the title?

edit: Furthermore the original intent of including garbage collection in the title was as an ironic twist based on the fact that ios has never had garbage collection. Maybe that didn't convey as well as I would have liked.

I should clarify. iOS does not have garbage collection and has never had garbage collection. The root of this bug is in old legacy cruft from the garbage collected days of OSX. The code is dormant in a lot of old CoreFoundation classes, and still causes unexpected behavior from time to time.

I should note that, while we saw something like 0.4% increased crash rate, we actually don't have a number to compare it against for memory crashes.

This is because if memory usage gets too high, the OS will send a kill signal to the process, which can be neither detected nor caught.

This means that in our original decision to use this fix, all we had was anecdotal evidence of untraceable crashes. Luckily we had dedicated QA that was keeping pretty solid track of them all, and they piled up.

In our case I think it was worth it.

Worked quite well for me, then started 404'ing. Load issues I presume.

Either way bravo, great idea.

I've been thinking about this since yesterday, and it seems like a really good solution for some use cases, but isn't there quite a bit of overhead to using a dispatche queue for fine-grained operations? I mean it seems like the overhead of cross-thread communication would severely outweigh a simple synchronous lock call.

Then again, if you can do things like background non-essential operations, then the higher-level benefits can probably outweigh that.

Hah, good catch! Fixing.

That would certainly be an interesting project, although the performance implications on a mobile platform may be an issue (although that's becoming more moot with each generation).

In this case, however, our goal was to take common, familiar interfaces and idioms in Objective C, and make them safer/more powerful.

Something more like channels-like would be quite useful, but it would likely be published under a different project.