[vlc-devel] [RFC 0/2] New executor API
rom1v at videolabs.io
Thu Aug 27 19:09:31 CEST 2020
On Thu, Aug 27, 2020 at 07:06:28PM +0300, Rémi Denis-Courmont wrote:
> Le torstaina 27. elokuuta 2020, 18.50.29 EEST Romain Vimont a écrit :
> > On Thu, Aug 27, 2020 at 05:47:49PM +0300, Rémi Denis-Courmont wrote:
> > > Le torstaina 27. elokuuta 2020, 17.32.10 EEST Romain Vimont a écrit :
> > > > Yes, but vlc_executor_Cancel() may "interrupt" the task at any time, so
> > > > you have to handle it anyway (timeout or not).
> > >
> > > That's never going to work, unless the runnable has its own killable
> > > process (which should be had for other reasons, notably I/O scheduling).
> > I don't understand why you say it can't work.
> You simply can't stop another thread arbitrarily.
Of course. That's why interrupt() is optional and its implementation is
provided by the user.
> 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,
> > Canceling a runnable does work. This is already what
> > background_worker_Cancel() provides, and with the vlc_executor_t it
> > calls the interrupt() callback:
> Unless the runnable is trivial and spends all its time waiting on a single
> "thing", it simply won't work.
> It also won't work if the runnable is I/O bound, as there are no sane ways to
> interrupt poll() in library code, even less read/recv and write/send
> functions. You can cancel poll(), or you can send a thread signal, but
> libraries have no ways to reserve a signal for their own use.
Yes, it only allows to interrupt where it's possible.
More information about the vlc-devel