Re: Sublclassing NSThread
Re: Sublclassing NSThread
- Subject: Re: Sublclassing NSThread
- From: "Michael Ash" <email@hidden>
- Date: Wed, 17 Dec 2008 12:51:57 -0500
On Wed, Dec 17, 2008 at 11:14 AM, Keith Duncan <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden