On Oct 11, 2014, at 1:01 AM, Steve Mills <sjmi...@mac.com> wrote: > OK, that makes sense. The docs for NSOperationQueue made it sound like it > would take care of all that for you, figuring out how many threads to create > based on current load, executing them as resources became available, etc. > I've set it to 16 just for testing and that seems to prevent the blocking I > was getting before. Except now the main thread blocks in the code that > creates and adds the tasks to the queue. I've just re-read the docs and found > the small section that talks about not flooding the queue with tons of > operations, but handling batches in each operation or using a completion > block to signal another operation to be created if there's still data left to > process. It sure would've helped if this section would've been highlighted > when I read it the first time.
In one app I’m creating up to 600 or so block operations at once (processing a list of files), it looks like it takes less than a couple tenths of a second so it doesn’t seem like it should be noticeable unless you are creating many thousands of operations, or invocation operations are extraordinarily slow to create. Keep in mind you can add operations to your queue from inside an operation executing on that queue so it would likely be trivial to change your code to generate the operations in a block operation. Jim _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
