[vlc-devel] [RFC 0/2] New executor API

[Pierre Ynard]

> It's not a question of use case. It's a question of why the generic
> framework should have to care about a given aspect, consdering that
> the specific runnable will have to do the heavy lifting anyhow.

The task framework provides the convenient service of handling,
registering and firing the timeouts. I think that's worth it: threading
code can be hard and error-prone, and if each runnable task is left
to implement it themselves, that's more duplicated code, which might
be done poorly, or the task might not bother implementing it all, or
it would just put its timer into the VLC timer API, which defeats the
purpose of introducing a new API.

Providing cooperative task interruption as part of the task framework
offers a simple and consistent interface for tasks to use: it nudges
task code developers towards using it and doing the right thing;
stricter policies can then even build on that to enforce that API users
correctly support task interruption. That can be especially relevant in
an applicative environment where framework developers and business code
developers are not the same people and don't share the same focus and
coding skills.

Moreover, whether the task is to be run, interrupted or cancelled can
depend on resource, scheduling, policy or technical constraints specific
to the task framework, that individual tasks may not be aware of, should
not be concerned about, or should not be expected or trusted to deal
with fairly.

A more advanced version is if the task framework aims at providing
efficient parallel computing under time or processing constraints, and
offers stock facilities that tasks can leverage, such as fork-join,
mapreduce or divide-and-conquer: then the task framework needs knowledge
of task cancellation to properly chain tasks together and interrupt
unfinished or unnecessary ones. But something that advanced might not be
something VLC needs.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."