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

[Pierre Ynard]

> Then, you could also consider a case where the client doesn't care
> about cancelling its tasks and leave them on the wild before going
> down,

Keeping a reference to tasks is not the same thing as keeping a
reference to the executor. Tasks will get consumed one way or another
eventually, regardless of whether the executor gets destroyed or not.

> but then why would you cancel those tasks instead of wait for them to
> be consumed?

You don't have to. That's a design decision. Perhaps because the design
is that termination should be quick, perhaps because tasks - whose
execution is not guaranteed by this API - are considered expendable.

> What if one of those tasks is «save the current settings»?

Then you probably want to run this synchronously instead, or at least
with an API that offers guarantees.

> Only the client knows what should be done with the task and I find it
> much complex to bend a generic async execution model to match what
> the clients might want to do while still expecting them to provide
> the correct interrupt method, instead of providing the async building
> blocks in a sane way and let the client handle what is specific to
> them.

The API is a framework. The way I see it, it's not bent around the
clients, instead it bends, influences, formats the tasks that are going
to be put into it, and the way clients are going to use it. Then maybe
you don't like the spirit of this framework, or find it unsuited, or are
confident in your do-it-yourself abilities, and it makes you not want to
use it; and that's a valid opinion.

> Multiple executor makes more sense in the design of an asynchronous
> system since you'll probably dedicate different pool to different
> usage. That's different from what you reference here though.

A single pool at the top level makes more sense to manage available
resources, as the top level has a global view of them, and otherwise
you can end up with different thread pools competing with each other
in a detrimental way: in big applications, sometimes you can even go
down into oversubscription and latency hell, with orders of magnitude
between the number of hardware CPU threads available on the system, and
the total number of logical threads across all the thread pools, all
fighting with each other to appropriate slices of runtime. This is fun.

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