@boredzo Thanks for clarifying. That makes my life much easier, like it was a few hours ago. :-)
@boredzo If there were per-thread state, I could not use separate queues per document. But it's moot since you say documents are fine.
@boredzo I'm thinking of the NSXMLDocument case where I'm dispatching multiple blocks per document on the same serial queue.
@boredzo You can't ensure that they won't be interleaved on the same thread. But it's OK, I guess, since not called from a callback.
@boredzo In that case, it is easy to confine two objects to separate threads. But if you confine to separate serial queues…
@boredzo I was thinking of long-lived objects (e.g. documents) that you call methods on.
@boredzo 10.8 RN only mention a problem with reentrancy. Implies that separate parsers/documents are OK if called from same parent method.
@boredzo So the docs have been wrong all these years? Do I always have to use a child thread, to avoid colliding with Cocoa on main thread?
@boredzo BTW, that contradicts the docs: "…NSXMLParser is a thread-safe class as long as any given instance is only used in one thread."
@boredzo So all bets are off if you're using GCD and don't know the actual thread? Is NSXMLDocument safe?
@jasperblues I think you just put "dynamic" after "func".
Doesn't seem to be anything wrong with my app's code signature. codesign just doesn't like VMware shared folders. Relieved but annoyed.
@jasperblues I agree with separate keywords, but I think “dynamic” should have been the default. Feels like having to type “nonfinal.”
@jasperblues That part I think they got right in b5. The concerns are now separated, and there’s no implied deprecation for “dynamic.”
@jasperblues And tag all your methods dynamic.
@nolobe_matt Getting SPF errors trying to reply to your e-mail. Tried multiple SMTP servers, so I think the issue's on your end.
@gte I'm having that problem, too, but alas it doesn't seem to be due to the cable.