On Jun 2, 2012, at 11:54 AM, Markus Spoettl wrote: > I'm still not seeing how queuePriority would solve the issue. Say you have a > queue with maxConcurrentOperationCount == 1 > > 1) You add operation (A), it starts executing > > 2) You add operation (B), (C), (D), (E), (F), (G), (H) and (I) in that order. > All wait > > Please explain how you suggest to use queuePriority in order to ensure the > waiting operations will execute in the reverse order: > > (I), (H), (G), (F), (E), (D), (C), (B).
Well, you could have each operation, as its first action, set the last operation in the queue to have high priority. If you don't like mixing that LIFO knowledge into the operation, you can have a separate operation class wrap another operation. It would re-prioritize the next operation and then call through to the wrapped operation's -start method. That said, I don't know that OP requires strict LIFO order. He just wants the operations associated with images which are scrolled into view to have higher priority than those which aren't. That can just be accomplished by setting the priority of operations as their associated images are scrolled into and out of view. The problem, as I understand it, is that IKImageView doesn't make it easy to detect that. Regards, Ken _______________________________________________ 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
