[vlc-devel] [RFC v2 1/2] executor: introduce new executor API

[Pierre Ynard]

> First, I'm not sure I see the point of supporting this use
> case. Here the fact there are two tasks is completely useless
> since they are the only ones running, one after the other and
> no parallel work can happen.
> 
> Then, since you'll need to wait for the tasks to complete
> anyway, you can just execute the task directly in foo, removing
> the need for the vlc_executor and the need to support this use
> case at all.

Splitting into two tasks can be done for convenience or for reasons of
code organization - not supporting it means favoring monolithic tasks
and code. Beyond that, it's not functionally equivalent either: you may
want to yield the worker thread to other tasks waiting for a chance to
run.

Then you say it yourself, there is no parallelism; but there could
be. It's common that parallelizable work is preceded or followed by
unparallelizable sections. There could be a first unparallelizable task,
which would then attempt to queue several parallel tasks. There's not
even any obligation that it would output results to wait for.

> I don't think it's reasonable to write the async framework
> while having sync use cases and situation. Thus, concrete
> examples might be a better fit for the design than minimal
> codes which can't really enjoy an async design.

Well, is it an async framework? It runs tasks in a thread pool. The API
doesn't say much about the sync or async nature of the tasks.

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