¿Utiliza NSOperationQueue como una stack de LIFO?

Necesito hacer una serie de llamadas de url (búsqueda de mosaicos de WMS). Quiero usar una stack de LIFO, por lo que la última llamada de url es la más importante. Quiero mostrar el mosaico en la pantalla ahora, no un mosaico que estaba en la pantalla hace 5 segundos después de un mosaico.

Puedo crear mi propia stack de un NSMutableArray, pero me pregunto si un NSOperationQueue se puede usar como una stack de LIFO.

Lamentablemente, creo que NSOperationQueue , como su nombre lo indica, solo se puede usar como queues, no como stacks. Para evitar tener que hacer un montón de tareas manuales, probablemente lo más fácil es tratar las queues como si fueran inmutables y mutar copyndo. P.ej

 - (NSOperationQueue *)addOperation:(NSOperation *)operation toHeadOfQueue:(NSOperationQueue *)queue { // suspending a queue prevents it from issuing new operations; it doesn't // pause any already ongoing operations. So we do this to prevent a race // condition as we copy operations from the queue queue.suspended = YES; // create a new queue NSOperationQueue *mutatedQueue = [[NSOperationQueue alloc] init]; // add the new operation at the head [mutatedQueue addOperation:operation]; // copy in all the preexisting operations that haven't yet started for(NSOperation *operation in [queue operations]) { if(!operation.isExecuting) [mutatedQueue addOperation:operation]; } // the caller should now ensure the original queue is disposed of... } /* ... elsewhere ... */ NSOperationQueue *newQueue = [self addOperation:newOperation toHeadOfQueue:operationQueue]; [operationQueue release]; operationQueue = newQueue; 

Parece que, en la actualidad, la liberación de una queue que sigue funcionando (como ocurrirá con la antigua queue de operaciones) no provoca que cancele todas las operaciones, pero eso no es un comportamiento documentado, por lo que probablemente no sea confiable. Si desea estar realmente seguro, el valor-key observa la propiedad operationCount en la queue antigua y la suelta cuando pasa a cero.

Puede establecer la prioridad de las operaciones en una queue de operaciones utilizando -[NSOperation setQueuePriority:] . Tendrá que reorganizar las prioridades de las operaciones existentes cada vez que agregue una operación, pero puede lograr algo así como lo que está buscando. En esencia, degradarías todas las viejas y darías la más nueva prioridad.

No estoy seguro de si todavía está buscando una solución, pero el mismo problema me ha estado molestando por un time, así que seguí adelante e implementé un package de operaciones aquí: https://github.com/cbrauchli/ CBOperationStack . Lo he usado con unos pocos cientos de operaciones de descarga y se ha resistido bien.

Tristemente, no puedes hacer eso sin toparte con algunos problemas complicados, porque:

Importante Siempre debe configurar las dependencies antes de ejecutar sus operaciones o agregarlas a una queue de operaciones. Las dependencies agregadas después no pueden impedir que se ejecute un object de operación dado. (De: Guía de progtwigción de concurrency: Configuración de dependencies de interoperación )

Echa un vistazo a esta pregunta relacionada: el método AFURLConnectionOperation 'start' se invoca antes de que esté listo y nunca más se vuelve a llamar después

Se encontró una implementación clara de las funciones stack / LIFO además de NSOperationQueue. Se puede usar como una categoría que extiende NSOperationQueue o una subclass NSOperationQueue LIFO.

https://github.com/nicklockwood/NSOperationStack