Re: NSOperationQueue
Re: NSOperationQueue
- Subject: Re: NSOperationQueue
- From: Kyle Sluder <email@hidden>
- Date: Sat, 02 Jun 2012 08:55:36 -0700
On Jun 2, 2012, at 8:38 AM, Markus Spoettl <email@hidden> wrote:
> On 6/2/12 4:57 PM, Charles Srstka wrote:
>> On Jun 1, 2012, at 10:23 PM, Graham Cox wrote:
>>
>>> On 02/06/2012, at 1:12 PM, Kyle Sluder wrote:
>>>
>>>> Give them a higher priority. You should be able to alter the priorities as the user scrolls, and NSOperationQueue will do the right thing.
>>>
>>>
>>> I tried this but it doesn't work - a bit of thought about how the ops are queued will show why no meaningful priority value can be assigned.
>>>
>>> At the moment that the operations are queued, there are some operations in the queue not yet run, and some running. The code that creates the operations doesn't know which ones are needed more urgently (the latest ones), so it can only assign a high priority to all of them, so they all end up with the same (high) priority and so we're back to square one.
>>
>> Setting the priority seems to work, in my testing:
>
> Prioritizing doesn't solve the LIFO problem the OP has. When you add a new prioritized operation you need to de-prioritize the ones that are already in the queue (in order to make sure your new operation executes first). Those de-prioritized operations execute in FIFO order.
I'm still not seeing the problem. Just set their queuePriority property. The order of operations is not fixed at the time of enqueueing, and NSOperation's properties are thread safe for a reason.
--Kyle Sluder
_______________________________________________
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