> On Oct 8, 2014, at 12:28 PM, Ken Thomases <k...@codeweavers.com> wrote: > > Queues are not like run loops nor threads. Your desire to have ongoing logic > occur on a particular queue seems odd to me.
I don't think it's odd to want an ongoing single flow of control for specific parts of the program. Limiting parallelism makes it a lot easier to reason about the code's behavior. You can create one of those with a background thread, but my understanding is that we're encouraged to use serial dispatch queues instead. I've certainly done this with threads in the past, but there's complexity with setting up the thread's main method that runs a runloop and knows how to exit when it's done; plus, newer system APIs seem to be moving away from runloops (e.g. NSURLSession.) This is part of why I still find the runloop-vs-queue-vs-NSOperation issue such a headache. Apple's given us a lot of concurrency options, and it's really unclear which ones to use when. Especially when a lot of the Cocoa classes work with only some of them but not others. (For example NSStream only supports runloop scheduling while NSURLSession only supports NSOperationQueues.) > The main purpose for custom queues would be to synchronize access to > specific resources. Why is there "logic on queue A" that's doing anything > other than briefly accessing a shared resource? I disagree about that, actually. The advice to wrap critical sections in dispatch_async calls turns out to produce a _lot_ of overhead. I briefly used it in some performance-sensitive code this spring, but had to rip it out because a large fraction of runtime was being spent in OS code that scheduled dispatch queues, copied/freed blocks, juggled retain counts, etc. It was a lot faster to just use @synchronized, and faster still to make the classes in question single-threaded and push the synchronization tasks up to a higher level of the code. (This isn't just obsessing over clock cycles; I'm literally talking about 2x performance improvements in high-level benchmarks.) —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
