> '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 tmp%100==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 (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
