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

[Romain Vimont]

On Thu, Aug 27, 2020 at 10:27:49AM +0200, Alexandre Janniaux wrote:
> 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.

That's a good point, but the runnable must be able to react to an
explicit call to vlc_executor_Cancel() anyway, so it must already be
able to handle an "interrupt" event at any time.

> 
> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel