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

[Alexandre Janniaux]

On Sat, Aug 29, 2020 at 12:57:49AM +0200, Pierre Ynard via vlc-devel wrote:
Hi,

> Date: Sat, 29 Aug 2020 00:57:49 +0200
> From: Pierre Ynard <linkfanel at yahoo.fr>
> To: vlc-devel at videolan.org
> Subject: Re: [vlc-devel] [RFC 0/2] New executor API
> User-Agent: Mutt/1.5.23 (2014-03-12)
>
> 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.

There seems to be a misunderstanding. I'm all in favor of
rewriting it. I've mentioned the existence of background
workers to Romain when he first presented his plans for the
vlc_executor.

I also agree that there are always different ways of writing
such frameworks and if it were the first iteration of it I
would certainly just accept it because it could be improved
later.

However it's not the first iteration and the same argument
applies to this patchset too. One could ask why change types,
naming, etc, in face of what it brings, and that's not about
«do-it-yourself» abilities.

Here, the design has been challenged on many points that were
in my opinion relevant given the needed substitution.
In particular, in the very core of the design, the inspiration
from the java executor is using exactly what Rémi and me have
been mentioning in this thread, meaning the task handle its
cancellation itself without taking care of synchronization
issuesm because the interruption mechanism is standard and
handled everywhere, and thus can be and must be handled
directly within the code. My main point of criticism here
have been that this patchset compensates the lack of unified
interruption mechanism by custom handlers, which could really
be done by the creator of the task directly.

The idea here have been to share the interruption code between
the timeout and the cancellation, but timeout is also keeping a
duplicate of functionality with vlc_timer for that.

Thus, I just suggest that we spend a few days thinking of the
scope first while thinking about how to weight and address the
challenged points, and try to avoid getting this personal.

> > 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.

As I said, it makes sense because tasks are not always alike,
though it doesn't necessarily applies here. I'm not inventing
it. Boost::asio has offered such features from the beginning
and it is usually well explained in almost every talk or
article mentioning this. Languages like Kotlin have put this
in the core of their coroutine designs and offers UI scope
context, side computation scope context and IO scope context.

And it's very easy to understand, listening and handling
sockets has not the same cost as converting a picture chroma
in CPU for example, both that you would not do in the UI thread
either.

Top level has a global view but lacks priorization of tasks.

How it fits for VLC is a different question, like I've written,
and I'd be glad that we explore more generic asynchronous design
in some part of VLC instead of rewriting command queues and using
background thread in general, though it's a much bigger task than
this patchset as it must fit within the design of a sandbox too,
to be future-proof.

Regards,
--
Alexandre Janniaux
Videolabs