Description

This way, instead of throwing away runners that aren't yet ready, we can give the runners more time to warm up. This requires some careful management in the Executor, Evaluator, and ExecutorPool classes: currently, all of our code assumes that an Executor is one-and-done, i.e. that there is a 1:1 relationship between evaluation calls and WASI runners, and that a new evaluation event always gets an Executor that's in a ready state.

Perhaps the HEARTBEAT signal can be read unconditionally at the start of evaluation (i.e., the executor sends it automatically when it's ready, rather than waiting for stdin). The state change from AWAITING_HEARTBEAT to EMPTY can happen in the background. The ExecutorPool can simply re-queue any Executor that isn't in the desired state. That way, at call time, there will be no need to think about that state change. In this case, we'd time out not during execute(), but when trying to acquire the runner from the ExecutorPool.

Desired behavior/Acceptance criteria (returned value, expected error, performance expectations, etc.)

• think about it
• maybe make a Phab task to do it, and then do it

Remove all the non-applicable tags from the "Tags" field, leave only the tags of the projects/repositories related to this task

Completion checklist

• Before closing this task, review one by one the checklist available here: https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Definition_of_Done#Back-end_Task/Bug_completion_checklist