That’s not what the documentation says:

> If YES, the current thread is blocked until all of the specified operations 
> finish executing. If NO, the operations are added to the queue and control 
> returns immediately to the caller.


So, if you’re experiencing different behavior, I would say that’s a bug that 
should be filed.

That doesn’t solve your question, though. Have you tried using dispatch 
semaphores? They’re a pretty easy way to synchronize tasks:

> dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
> 
> [self performLongRunningAsynchronousTaskWithCompletionHandler:^{
>       dispatch_semaphore_signal(semaphore);
> }];
> 
> dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);


dispatch_semaphore_wait() will block until the semaphore is signaled at the end 
of the block.


Jeff Kelley

slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org

On Jun 3, 2014, at 12:17 PM, Dave <d...@looktowindward.com> wrote:

> I’ve tried that, addOperations:waitUntilFinished: waits for operations 
> currently queued to finish before adding the current operation, it doesn’t 
> Add it to the queue and then wait for it to complete which is what I want.
> 
> Thanks
> Dave
> 
> On 3 Jun 2014, at 19:26, Jeffrey Robert Kelley <slauncha...@gmail.com> wrote:
> 
>> I think you’re looking for NSOperationQueue’s 
>> -addOperations:waitUntilFinished: method. Should do what you want.
>> 
>> 
>> Jeff Kelley
>> 
>> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
>> 
>> On Jun 3, 2014, at 5:51 AM, Dave <d...@looktowindward.com> wrote:
>> 
>>> Hi,
>>> 
>>> I think this has been covered before, but all the searches I’ve done don’t 
>>> really cover what I’d like to do.
>>> 
>>> I have an API that has two modes of operation, Sync and Async.
>>> 
>>> In Sync mode calls to the API MUST be on a background thread and the data 
>>> is returned to the caller with a possibility that the thread is blocked 
>>> until the operation has completed.
>>> 
>>> In Async mode calls to the API may be on the background thread or the Main 
>>> Thread, a delegate is passed to the API method which returns immediately 
>>> and the Delegate is called when the operation completes or fails.
>>> 
>>> This all works, however I have some existing code that I’d like to have the 
>>> same API and be called by a “Manager Class” which calls the correct 
>>> underlying API depending on the context, e.g.
>>> 
>>> AppLayer—>ManagerClass—>API_A
>>>                                           —>API_B
>>> 
>>> API_A is the existing API supporting the Sync/Async interface.
>>> API_B is the one I wish to create.
>>> 
>>> The problem is that the existing code uses NSOperationQueue/NSOperation 
>>> accomplish it’s task, this works fine in Async mode, it was easy enough to 
>>> adapt to call the Delegate methods, but I’m not sure how to implement Sync 
>>> mode?
>>> 
>>> Basically I want to add the NSOperation to the queue and then wait for it 
>>> to complete before returning with the results.
>>> 
>>> Any ideas suggestions would be greatly appreciated as there seem to be a 
>>> lot of conflicting advice out there on how to do this and I’ve not been 
>>> able to find anything worked as described above.
>>> 
>>> Thanks a lot.
>>> 
>>> All the Best
>>> Dave
>>> 
>>> 
>>> _______________________________________________
>>> 
>>> 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/slaunchaman%40gmail.com
>>> 
>>> This email sent to slauncha...@gmail.com
>> 
>> _______________________________________________
>> 
>> 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/dave%40looktowindward.com
>> 
>> This email sent to d...@looktowindward.com
> 
> 
> _______________________________________________
> 
> 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/slaunchaman%40gmail.com
> 
> This email sent to slauncha...@gmail.com

_______________________________________________

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

Reply via email to