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

[Romain Vimont]

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,
etc.)

> > 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.