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

[Alexandre Janniaux]

Hi,

On Fri, Aug 28, 2020 at 06:09:30PM +0200, Pierre Ynard via vlc-devel wrote:
> Date: Fri, 28 Aug 2020 18:09:30 +0200
> From: Pierre Ynard <linkfanel at yahoo.fr>
> To: vlc-devel at videolan.org
> Subject: Re: [vlc-devel] [RFC 0/2] New executor API
> User-Agent: Mutt/1.5.23 (2014-03-12)
>
> > 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.
>
> I'm not sure what your point is, but the vlc_executor can be killed
> without killing its users first: it just needs to stop accepting new
> tasks, then cancel/time out/wait out all current tasks, then join all
> its worker threads and exit.

My point is that as long as vlc_executor has not shared ownership
(ie. is not refcounted here), it must be destroyed after other
objects that might be using it. And even if you refcount it, it
means that it's not destroyed as long as the other objects are
using it. Otherwise you have a dangling pointer which is, imho,
a very bad design.

Then, you could also consider a case where the client doesn't
care about cancelling its tasks and leave them on the wild
before going down, but then why would you cancel those tasks
instead of wait for them to be consumed? What if one of those
tasks is «save the current settings»? Only the client knows
what should be done with the task and I find it much complex
to bend a generic async execution model to match what the
clients might want to do while still expecting them to provide
the correct interrupt method, instead of providing the async
building blocks in a sane way and let the client handle what
is specific to them.

> Now if each user wants to create and use its own dedicated executor and
> thread pool, then obviously it would kill its dedicated executor before
> killing itself; but it might make more sense that the core provides a
> single executor instance with a common thread pool, and keep it hidden
> behind the API, in which case users hold no reference to the executor.

Multiple executor makes more sense in the design of an asynchronous
system since you'll probably dedicate different pool to different
usage. That's different from what you reference here though.

But in the very construct you expose here, you see that if you can
call the API at any moment to add a new task, it's the same as
having a reference to the executor, except if you make the API
functions able to fail so as to refuse new tasks -- which works
yes, but then what is the trade-off when it comes to complexity?

Regards,
--
Alexandre Janniaux
Videolabs