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

[Romain Vimont]

On Thu, Aug 27, 2020 at 08:42:49PM +0300, Rémi Denis-Courmont wrote:
> Le torstaina 27. elokuuta 2020, 20.09.31 EEST Romain Vimont a écrit :
> > > You can use thread cancellation, if the threaded code supports it - but
> > > most likely it doesn't, and there is a lack of static analysis support to
> > > verify basic cancellation mistakes.
> > > 
> > > Again, it's much much easier and less error-prone to have a time-out
> > > within
> > > the thread.
> > 
> > But we must be able to cancel tasks like we currently do (preparsing,
> > etc.)
> 
> 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. Timeout and cancelation share the same purpose:
stop the current job when possible. A timeout is just a cancelation
where the deadline is known in advance.

I think it is a good thing that users don't have to implement timeout
and cancelation in two totally different ways.

> In fact, I don't see why you need the interrupt callback at all. The owner of 
> the runnable has to know how to interrupt the runnable anyway. No need for the 
> generic framework to know that any more than it needs to know the time-out.

 - vlc_executor_Cancel() also cancels tasks without calling run() if
   they are canceled before execution.
 - all tasks are canceled on vlc_executor_Delete() (if I close VLC, I
   want the current preparsing tasks to be "interrupted").