Re: Sublclassing NSThread
Re: Sublclassing NSThread
- Subject: Re: Sublclassing NSThread
- From: "Michael Ash" <email@hidden>
- Date: Wed, 17 Dec 2008 10:29:44 -0500
On Wed, Dec 17, 2008 at 4:49 AM, Jean-Daniel Dupas
<email@hidden> wrote:
>
> Le 17 déc. 08 à 10:32, Jean-Daniel Dupas a écrit :
>
> And before you go off using NSOperationQueue, you should be aware that
>
> it's broken on Leopard, as described in this thread:
>
> http://www.cocoabuilder.com/archive/message/cocoa/2008/10/30/221452
>
>
> We already discuss this issues, and I agree with previous post that said you
> misuse it:
>
> http://www.cocoabuilder.com/archive/message/cocoa/2008/11/26/223819
>
>
> I think NSOperationQueue should be used like this instead:
> The process uses almost 200% of my Core 2 Duo proc and maybe i'm wrong, but
> I do not managed to crash it.
Yes, it's been established that using only a single NSOperationQueue
avoids the crash.
However that is completely and utterly *useless* because there's
absolutely no way to guarantee that only a single NSOperationQueue
exists in your process. You could arrange all of your code to only use
one. But Cocoa could use one as well, 100% legally, and the moment it
does so, *crash*.
Furthermore I dispute that I was incorrectly using NSOperationQueue,
as the technique I was using came straight from an Apple employee. In
any case it's irrelevant to the question at hand, since it is
impossible to use NSOperationQueue in a manner which cannot trigger
this bug, unless you do nothing interesting with any frameworks
anywhere ever.
Modify your code slightly as follows:
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
NSOperationQueue *queue2 = [[NSOperationQueue alloc] init];
int i;
for(i = 0; i < 10; i++)
[testers addObject:[[[Tester alloc]
initWithQueue:(i%2)?queue:queue2] autorelease]];
Run it, watch it crash. Now imagine that queue2 is buried in
Foundation somewhere, and the Tester objects that use it likewise, and
that there's absolutely nothing you could do to prevent that crash if
that were the case.
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