Re: iOS - NSOperation/NSOperationQueue Question
Re: iOS - NSOperation/NSOperationQueue Question
- Subject: Re: iOS - NSOperation/NSOperationQueue Question
- From: Dave <email@hidden>
- Date: Wed, 04 Jun 2014 09:21:37 +0100
Hi,
Yes, the documentation is wrong or confusing at best, I’ve tried it, it doesn’t work. I think it’s meant for a number of operations that need to wait for the preceding operation to complete before the next one continues.
I also wondered if the NSOperation “waitUntilFinished” method might work, but it doesn’t seem to either. I’m about to revisit this, I did the testing a while back but had to leave it to get something else done. I’ve got a few more things I need to do this morning and then I’ll be at a point where I can investigate again.
About your dispatch semaphore suggestion, do you mean use it instead of an NSOperation or as well as?
Thanks a lot
Dave
On 3 Jun 2014, at 22:54, Jeffrey Robert Kelley <email@hidden> wrote:
> 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
>
> email@hidden | @SlaunchaMan | jeffkelley.org
>
> On Jun 3, 2014, at 12:17 PM, Dave <email@hidden> 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 <email@hidden> wrote:
>>
>>> I think you’re looking for NSOperationQueue’s -addOperations:waitUntilFinished: method. Should do what you want.
>>>
>>>
>>> Jeff Kelley
>>>
>>> email@hidden | @SlaunchaMan | jeffkelley.org
>>>
>>> On Jun 3, 2014, at 5:51 AM, Dave <email@hidden> 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 (email@hidden)
>>>>
>>>> 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:
>>>>
>>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> 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:
>>>
>>> This email sent to email@hidden
>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden