La cola de trabajos

Por qué una cola y no lanzar todo

La última fila es la de producto: «tres de veinte» es una información mucho mejor que veinte barras al 40%.

La forma

pub enum Estado { Pendiente, Corriendo { progreso: f32 }, Hecho, Fallido(String), Cancelado }pub struct Trabajo {    pub id: Uuid,    pub descripcion: String,        // lo que el usuario ve    pub estado: Estado,}pub struct Cola {    trabajos: RwLock<Vec<Trabajo>>,    semaforo: Semaphore,            // cuántos a la vez}

Tres decisiones:

• El semáforo fija la concurrencia y su valor por omisión razonable es dos, o el número de núcleos partido por dos. No el número de núcleos: la herramienta que lanzas probablemente ya usa varios por su cuenta.
• El trabajo lleva una descripción legible, no un identificador. Es lo que se muestra.
• Y el estado es un enumerado con los cinco casos, incluido cancelado, que suele faltar y luego hay que distinguirlo de fallido.

Informar sin saturar

Lo del nivel 40.3, aplicado a varias fuentes:

• Un solo evento con el estado de la cola entera, emitido como mucho cada doscientos milisegundos, en vez de un evento por trabajo.
• Que el frontend pida el estado completo al abrir el panel, y luego reciba actualizaciones. Así no hace falta que los eventos lleven todo.
• Y no emitir nada si no ha cambiado nada perceptible.

Con eso, veinte trabajos producen cinco eventos por segundo en total, en vez de varios cientos.

Cancelar

Tres niveles, y los tres hacen falta:

El estado intermedio de «cancelando» importa: sin él, el usuario pulsa cancelar, no pasa nada visible durante tres segundos, y vuelve a pulsar.

Qué pasa al cerrar

La decisión que hay que tomar explícitamente:

• Cancelar todo y salir es lo simple y lo correcto para trabajos cortos.
• Avisar de que hay trabajos en curso y dejar elegir es lo correcto cuando son largos: «hay 3 conversiones en curso, ¿salir de todos modos?».
• Y continuar en segundo plano solo si tu aplicación tiene presencia fuera de la ventana —bandeja, nivel 50—; si no, el usuario cierra y cree que ha terminado.

Lo que no vale es salir en silencio con trabajos a medias, dejando ficheros incompletos que el usuario descubrirá luego.

Persistir la cola

Y la pregunta final: ¿los trabajos pendientes sobreviven a un cierre?

Para la mayoría de las aplicaciones, no, y está bien: una cola persistente exige que cada trabajo se pueda reanudar o repetir sin efectos raros, y eso es trabajo. Si lo haces, dos requisitos: que los trabajos sean idempotentes —repetir uno no rompe nada— y que al arrancar se le pregunte al usuario en vez de reanudar solo, porque puede haber cambiado de idea en el tiempo transcurrido.