On Wed, Dec 17, 2008 at 11:14 AM, Keith Duncan <keith_...@mac.com> wrote: > > On 17 Dec 2008, at 15:41, Jean-Daniel Dupas wrote: > >>> because there's absolutely no way to guarantee that only a single >>> NSOperationQueue >>> exists in your process > > Couldn't you swizzle +[NSOperationQueue alloc] to return a singleton? Sure > it's a hack, but a simple one that can be #ifdefed out for post Leopard > builds. And would fix the problem for now if you've already architected a > project around operation queues.
(It would have to be +allocWithZone: if you wanted to be absolutely sure to catch everything, actually.) You could, but you'd be opening yourself up to more trouble. NSOperationQueue does have a certain amount of per-instance configurability and state. If some external code created one and set the max concurrent operations to a different value, or suspended it, or used cancelAllOperations, you'd be utterly hosed. NSOperationQueue also exposes an -operations method which is *supposed* to be useful for watching the state of the queue (although this functionality is IMO dubious and my replacement doesn't, and really can't, include it) and mixing everybody's operations together into one big basket won't do anything good for that. There's also no guarantee that a single NSOperationQueue is safe even if you can guarantee there are no others. Nobody has managed to replicate my crash with it yet, but that could just mean that it's much more rare in that case, not that it's impossible. (It certainly could be impossible, just saying we don't know.) And as Robert Marini points out, there are more bugs than just this one, and this won't protect you from those. Unfortunately it seems that there is no quick fix. If you've already built your project around operation queues then IMO the best fix is to imitate NSOperationQueue, minus the features you don't need and the bugs you don't want. So far this approach has worked out great for me. Mike _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
