The way we're handling them is to have a global timer that is reset at
any point a task is ran.
This gives a maximum amount of chances to any task to have its
dependencies resolve.
A minimum of 60s is given, but in reality the chances are the conditions
for trying to resolve were already present before the timeout started
counting towards that particular dependency.
Note that a long running task, when successfully ran, does not cause the
timeout to be reached.
E.g. at 10s of timeout a task is started, the loop is not executed until
the task exits. When it exits the branch followed is for a task that
ran, which means that even if the task took 70s total (which gives us 80
seconds) a timeout of 60s wouldn't apply here.
Though, please, don't make your tasks take that much time to run!
This is to ensure "UX-friendly" tasks gets run ASAP.
Quickly explained, this makes sure that the top tasks (e.g. Splash) gets
ran as soon as possible.
Given the list:
- Splash
- Graphics
- AAA
- BBB
- CCC
If `Graphics` ends up running, and AAA, BBB and CCC can too, Splash will
have to wait until all those tasks got ran once!
Not ideal for UX, if e.g. BBB takes time to *run* and we can't show the
progress to users!
The added cost of restarting the queue is minimal with tests I ran. It
was not more than a tenth of a second, and could even be rounding
errors.
This is used to ensure mount points are mounted with the right options,
if for some reason they were already mounted.
Reasons they could be mounted? They could have been required for things
like logging the boot.
This ensures graphical progress is shown ASAP when dependencies are
equally likely to run.
Otherwise, when the graphical step was ready, and switchroot about to
run, the shell step could run before the splash. This means that, in
practice, a long running task like e2fsck could have prevented the
splash to show. It doesn't make sense to make the other tasks depend on
a splash task!
There is no intention to implement any other special-cased ordering. If
there is the need to, it might mean that there is a deficiency in the
design.
This is partly to reduce the amount of loops it needs to run, but mainly
to control the order rather than rely on the order they were added in.
The control of order seems weird in a dependency-based system, but it'll
be used mainly for one thing in the next commit...
Instead, rely on targets.
Additionally removes the "Boot" special dependency which only made sense
when it was expected that having no dependency was an error.
