search

python-trio / trimeter

(not ready yet) A simple but powerful job scheduler for Trio programs
https://trimeter.readthedocs.io
Other
63 stars 3 forks source link

Should we provide an ordered=True option? #5

Open njsmith opened 6 years ago

njsmith commented 6 years ago

Right now, the incremental result reporting always reports results as they're ready, so the order of the output doesn't necessarily match the order of the input. (Except for run_all, since it's not incremental anyway.)

Should we provide an option ordered=True to request that the output order must match the input order?

If we do then there's some subtle interaction with backpressure: if task 0 is slow, we probably don't want to buffer up results from tasks 1...10000 while waiting for task 0 to finish. I think the way to avoid this is to do the reordering directly inside the workers, rather than with a separate buffering/reordering task. When ordered=True, have each worker wait for the previous work to report its result before this worker reports its result. And worker tasks still count against the metered limits until after they report their result.

jtrakk commented 4 years ago

I can imagine users accidentally relying on an ordering assumption and getting wrong results. Having unordered_run_on_each() be a separate function might be safer.

oremanj commented 4 years ago

I think Trio's nondeterministic scheduling will foil most order-preservation assumptions pretty quickly, so I'm not worried about issues with the default being ordered.

I think ordered=True would be useful to support, specifically because it's the sort of thing that's hard for someone else to implement on top of trimeter (since the ideal implementation would be within the worker).