Re: NSOperationQueue question
Re: NSOperationQueue question
- Subject: Re: NSOperationQueue question
- From: Tim Murison <email@hidden>
- Date: Fri, 07 Aug 2009 16:05:44 -0400
- Thread-topic: NSOperationQueue question
> 'setMaxConcurrentOperationCount' specifies the number of concurrently
> executing threads. I don't see anything in the documentation that
> guarantees it will control the number of concurrently existing
> threads. Threads may exist waiting to execute, and threads will exist
> for some period of time after they finish execution (in the
> NSOperation sense of isExecuting, in all cases).
I understand this, however 65 seems rather excessive. Also, I have a more
complex version of the code in my application that and it will use far fewer
threads.
> Also, because globalCounter is being changed by the operations,
> there's no guarantee the main thread will ever see tmp0==0, if
> you're unlucky, so that collectExhaustively thing is unreliable.
I know, but it happens frequently enough that I shouldn't use memory like
mad. If you run the program, you'll see the collection is done roughtly
every 1-2 seconds.
> Also, because you're putting the main thread in a hard loop, you're
> stealing CPU time that might be used for operations and/or the garbage
> collector. Your main thread and your operations are all asking for
> 100% of the CPU cores they're running in, which is going to make it
> hard for the garbage collector to get the compute time it needs.
>
> All in all, it makes me want to ask what you're trying to achieve by
> this. To prove that you can outrun the collector? You can.
This is meant to be a toy program to illustrate a problem, not a useful use
of the NSOperationQueue.
In my real application I have a memory leak that I can trace to operations
not being release by the operation queue. This program is meant to show that
in the simplest way possible.
***********************************************************************
This e-mail and its attachments are confidential, legally privileged, may be subject to copyright and sent solely for the attention of the addressee(s).
Any unauthorized use or disclosure is prohibited. Statements and opinions expressed in this e-mail may not represent those of Radialpoint.
Le contenu de ce courriel est confidentiel, privilégié et peut être soumis à des droits d'auteur. Il est envoyé à l'intention exclusive de son ou de ses
destinataires. Il est interdit de l'utiliser ou de le divulguer sans autorisation. Les opinions exprimées dans le présent courriel peuvent diverger de celles de Radialpoint.
_______________________________________________
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