When you try to mix synchronous (one request at a time) and asynchronous calls (the task is set up and a completion handler is called after the original set up calls) together like this, you have to start doing lots of extra management across queues. This pattern can apply across other asynchronous APIs. If you have 50 requests to execute, in the worst case, you have 50 requests happening with 1 doing work and 49 blocked. Those 49 blocked requests may hog resources unnecessarily.
A different way to do this that avoids all that management is to only start the new request once an existing request has finished. If you have 50 requests to execute, in the worst case, you have 1 request happening with 1 doing work and none blocked. The 49 requests not called yet will not tie up any resources. Based on what I understand to be your requirements, and in a very general way, I would do this (written in email): 1. Create a mutable array 2. Create methods that add requests to the end and remove requests from the beginning of that array with a common lock around those operations. There are many ways to do this lock. An easy one to code in Objective-C is the @synchronized block with the array being the object. 3. Call the locking method to add each request as needed. 4. When a request is added such that it's the first one in the array, set up your asynchronous request for it within the locking method. 5. At the end of the request's completion block (all completion blocks should be the same), call the locking method that removes the first request from the array. If there's another request in the array, set up your asynchronous request on it within the locking method. 6. Repeat 5 till empty. Essentially, if not for the asynchronous completion blocks, this is the same design you would use for synchronous requests except for the placement of the completion block and timing of its execution. When I refer to requests, these can be as simple as some application-defined value and actual NSURL and NSURLSession objects not created until step 4/5. -- Gary L. Wade (Sent from my iPad) http://www.garywade.com/ > On Jun 28, 2016, at 5:03 PM, Peter Tomaselli <vast.gra...@gmail.com> wrote: > > I have not a lot of Cocoa experience here, so I am legitimately asking this > question, no snark intended: what’s the advantage to building a home-made > “serial” “queue” as opposed to just using an actual serial operation queue? > Haven’t you just described the first few steps one would take were one to set > out to reimplement NSOperationQueue? > > FWIW (and as I mentioned, I am an eminently ignorable person when it comes to > Cocoa expertise), I sort of see the essence of the “async” flavor of > NSOperation as being to provide definitive signaling when an otherwise > asynchronous operation is really “finished“ — for whatever business > definition of “finished” one requires. So I don’t completely agree that this > would be “shoehorning”; seems right on the money to me. > > Just one opinion! Cheers, > > Peter > >> On Jun 28, 2016, at 6:50 PM, "Gary L. Wade" <garyw...@desisoftsystems.com> >> wrote: >> >> Based on his desire to do this serially, he would need a serial queue, and >> he's using asynchronous requests, so succeeding calls from his completion >> handler with a simple array in queue pattern is simpler than shoehorning it >> all into dispatch queues. >> -- >> Gary L. Wade (Sent from my iPhone) >> http://www.garywade.com/ >> >>> On Jun 28, 2016, at 3:45 PM, Alex Zavatone <z...@mac.com> wrote: >>> >>> Would a dispatch queue get what he's looking for? > _______________________________________________ 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
