Currently nevermore is oriented towards batches of operations (including infinite batches) where a lot of jobs go into a black box and a lot of settlements come out (in any order).
However, for the case that individual ad-hoc requests need to be constrained by a limit-pool, (e.g. never have more than 10000 upstream requests to any server, never have more than 8 simultaneous disk reads) it would be convenient to have an interface like p-limit (limit(job)) or p-queue (queue.add(job)) that allows an individual task to be trivially constrained and tracked (and you can directly await the return value of the wrapped job or the scheduling call, rather than having to interact with a pipeline interface).
Currently
nevermore
is oriented towards batches of operations (including infinite batches) where a lot of jobs go into a black box and a lot of settlements come out (in any order).However, for the case that individual ad-hoc requests need to be constrained by a limit-pool, (e.g. never have more than 10000 upstream requests to any server, never have more than 8 simultaneous disk reads) it would be convenient to have an interface like
p-limit
(limit(job)
) orp-queue
(queue.add(job)
) that allows an individual task to be trivially constrained and tracked (and you can directly await the return value of the wrapped job or the scheduling call, rather than having to interact with a pipeline interface).A typical interface might be like...