Re: NSOperationQueue
Re: NSOperationQueue
- Subject: Re: NSOperationQueue
- From: Markus Spoettl <email@hidden>
- Date: Sat, 02 Jun 2012 17:38:01 +0200
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 had the same problem and ended up maintaining my own pool which adds the most
recently added operation to the queue first (with only one operation in the
queue at any time). It's ridiculously complicated, even a generic integer based
priority would do. I fail to understand why someone thought it's a good idea to
limit it to 5 distinct settings.
Regards
Markus
--
__________________________________________
Markus Spoettl
_______________________________________________
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