[vlc-devel] [RFC 0/2] New executor API
rom1v at videolabs.io
Thu Aug 27 21:13:37 CEST 2020
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").
More information about the vlc-devel