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

[Alexandre Janniaux]

Hi,

On Thu, Aug 27, 2020 at 10:28:58PM +0300, Rémi Denis-Courmont wrote:
> Le torstaina 27. elokuuta 2020, 22.13.37 EEST Romain Vimont a écrit :
> > > So the runnable will be using poll(), vlc_cond_t, vlc_sem_t or some other
> > > wait method that supports timing-out. It might as well use that time-out
> > > capability instead of relying on a thread for the sole purpose of maybe
> > > (ab)using the interrupt callback on time-out.
> >
> > Yes, if you only want timeout, but not "unexpected" cancelation, that
> > works (and is better).
> >
> > > Besides, timing out is an error that deserves logging. Interrupt is not.
> > > So using the same callback for both purpose looks dubious to me.
> >
> > The goal is simplicity.
>
> By making things more complicated. Yeah right...

I agree with Remi, if you want simplicity, the best thing
would be to limit the asynchronous framework to the
asynchronous execution and signalling like almost every other
asynchronous framework.

Especially since youǘe talked about some `future` object, and
thus a pro-actor model which doesn't have ways to do
signalling from the outside of the asynchronous framework to
the task by itself in almost all implementation, and instead
have each layer of promise being able to return either a result
or an error that the future will catch, and an internal
composition rule for each layer's result.

In the case the vlc_executor is killed, the preparser client
needs to be killed first since it is using the executor, and
thus can cancel its tasks internally directly, which might be
at the middle of the preprocessing, at the beginning or right
before the end. It's much less convoluted than having the
preparser client use the vlc_executor to cancel the taks, which
will just really call the preparser specific cancellation code
anyway.

Regards,
--
Alexandre Janniaux
Videolabs