RxDart vs FxDart › #35 · Obtener de 4 en 4, resultados en orden

Obtener de 4 en 4, resultados en orden

Gana FxDart async

• fx
• toAsync
• mapConcurrent

Requisito

Obtén ocho perfiles de usuario cuyos tiempos de respuesta difieren, manteniendo como mucho 4 peticiones en vuelo a la vez — e imprime los resultados en orden de origen (el usuario 1 primero), más el máximo de peticiones en vuelo observado como prueba del límite. Los retardos están en el código; las dos versiones deben imprimir las líneas que aparecen bajo Salida esperada.

user#1
user#2
user#3
user#4
user#5
user#6
user#7
user#8
max in flight: 4

Lado a lado

Por qué difieren

Ambos lados acotan la concurrencia en un operador, y el contador compartido muestra que ambos alcanzan de verdad 4 en vuelo. La división es por el orden. flatMap(maxConcurrent: 4) es una fusión: emite cada resultado interno en el momento en que se completa, así que con estos retardos el usuario 7 (10 ms) se imprimiría antes que el usuario 1 (80 ms). Para cumplir el requisito el lado RxDart etiqueta cada resultado con su id, lo recoge todo y ordena al final — el orden que tenía la fuente lo destruye la fusión y hay que reconstruirlo a mano al terminar.

mapConcurrent(4, fetch) nunca pierde el orden en primer lugar. En un pipeline pull, la concurrencia es una propiedad de la demanda, no de la entrega: el operador lanza cuatro pulls solapados pero entrega los resultados aguas abajo en el orden en que se pidieron, reteniendo una llegada rápida y tardía hasta que sus predecesoras más lentas hayan salido. Acotado-y-ordenado es la forma que la mayoría del trabajo por lotes realmente quiere — resultados alineados con las entradas, límites de tasa respetados — y aquí es el comportamiento por defecto en lugar de una reconstrucción. Cuando el orden de terminación es lo que de verdad quieres, eso también existe — concurrentPool, el siguiente ejemplo — pero es la variante que eliges, no el comportamiento que deshaces.