You mentioned creating and managing threads on your own, but that’s what NSOperationQueue —and the lower-level DispatchQueue— does. It also will be more efficient with thread management since it has an intimate understanding of the capabilities of the processor, etc., and will work to do the “right thing” on a per-device basis.
By leveraging NSOperationQueue and then keeping each of the queue operations focused on a single file then you’re not complicating the management of what to do next since most of that is handled for you. Let NSManagedObjectQueue do the heavy lifting (scheduling work) and focus on your part of the task (performing the work). Steve > On Aug 16, 2022, at 8:41 AM, Gabriel Zachmann <z...@cs.uni-bremen.de> wrote: > > That is a good idea. Thanks a lot! > > Maybe, I can turn this into more fine-grained, dynamic load balancing (or > latency hiding), as follows: > create a number of threads (workers); > as soon as a worker is finished with their "current" image, it gets the next > one (a piece of work) out of the list, processes it, and stores the iso_date > in the output array (dates_and_times). > Both accesses to the pointer to the currently next piece of work, and the > output array would need to be made exclusive, of course. > > Best regards, Gabriel _______________________________________________ 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
