• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Sublclassing NSThread
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sublclassing NSThread


  • Subject: Re: Sublclassing NSThread
  • From: Jean-Daniel Dupas <email@hidden>
  • Date: Wed, 17 Dec 2008 16:41:34 +0100


Le 17 déc. 08 à 16:29, Michael Ash a écrit :

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.

touché ! OK, I see the point.



_______________________________________________

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


  • Follow-Ups:
    • Re: Sublclassing NSThread
      • From: Keith Duncan <email@hidden>
References: 
 >Sublclassing NSThread (From: Brad O'Hearne <email@hidden>)
 >Re: Sublclassing NSThread (From: "Shawn Erickson" <email@hidden>)
 >Re: Sublclassing NSThread (From: "Bradley S. O'Hearne" <email@hidden>)
 >Re: Sublclassing NSThread (From: "Michael Ash" <email@hidden>)
 >Re: Sublclassing NSThread (From: Jean-Daniel Dupas <email@hidden>)
 >Re: Sublclassing NSThread (From: Jean-Daniel Dupas <email@hidden>)
 >Re: Sublclassing NSThread (From: "Michael Ash" <email@hidden>)

  • Prev by Date: Re: More - Safari Download Security Alerts
  • Next by Date: Re: More - Safari Download Security Alerts
  • Previous by thread: Re: Sublclassing NSThread
  • Next by thread: Re: Sublclassing NSThread
  • Index(es):
    • Date
    • Thread