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

[Alexandre Janniaux]

Hi,

I agree with Remi on the timeout handling.

Especially since synchronization and threading is hard, we
should not split the termination call from the thread the
task is running on. It's much easier to compute a deadline
at the beginning of the task and either check it regularily
or drop timeout variants of the wait functions if needed.

An external timeout service could also be added if needed,
but at the discretion of each and every task, without the
need for it to be part of the main API.

Regards,
--
Alexandre Janniaux
Videolabs

On Thu, Aug 27, 2020 at 05:28:20AM +0200, Pierre Ynard via vlc-devel wrote:
> Date: Thu, 27 Aug 2020 05:28:20 +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)
>
> > 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."

> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel