Question

I try to authenticate my app with Twitter with following code: pastebin

However, if I remove the (useless?) loop line 23ff

for (ACAccount *acc in arrayOfAccounts) {
    [acc accountType].identifier;
    //Otherwise the identifier get lost - god knows why -__-
}

the acc.type becomes (null) when it gets executed further in
AccountHandler checkAccountOf:acc. If I leave the loop in, the type is correctly set.
I am pretty sure it has to do with the fact that I am in a block and then move on to the main queue, but I am wondering if I am doing something wrong? This loop does not look like sth I am supposed to have to do.

Something kinda similar happened here.

Answer 1

ACAccounts are not thread safe. You should use them only on the thread that they originate. And for this purpose you can read ‘thread’ as ‘queue’.

While I’ve not seen formal documentation of that, if you NSLog an account you’ll see that it’s a Core Data object and the lack of thread safety on Core Data objects is well documented.

The specific behaviour is that a Core Data object can be a fault. That means that what you’re holding is a reference to the object but not the actual object. When you try to access a property the object will be loaded into memory.

What Core Data is doing underneath is caching things in memory and returning faults until it knows that an object is really needed. The efficient coordination of that cache is what limits individual instances of the Core Data object that coordinates objects to a single thread.

If you do the action that should bring the object into memory on the wrong thread — which is what happens when you access identifier here — then the behaviour is undefined. You could just get a nil result or you could crash your application.

(aside: the reason that Core Data works like this is that it stores an object graph, so possibly 1000s of interconnected objects, and you can traverse it just like any other group of objects. However you don’t normally want to pay the costs associated with loading every single one of them into memory just to access whatever usually tiny subset of information you’re going to use, so it needs a way of providing a normal Objective-C interface while lazily loading)

The code you’ve linked to skirts around that issue by ensuring that the objects are in the cache, and hence in memory, before queue hopping. So the ‘fetch from store’ step occurs on the correct queue. However the code is nevertheless entirely unsafe because objects may transition from being in memory back to being faults according to whatever logic Core Data cares to apply.

The author obviously thinks they’ve found some bug on Apple’s part. They haven’t, they’ve merely decided to assume something is thread safe when it isn’t and have then found a way of relying on undefined behaviour that happened to work in their tests.

Moral of the story: keep the accounts themselves on a single thread. If you want to do some processing with the properties of an account then collect the relevant properties themselves as fundamental Foundation objects and post those off.