On Jun 2, 2012, at 8:38 AM, Markus Spoettl <ms_li...@shiftoption.com> 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 (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
