[vlc-devel] [RFC v2 1/2] executor: introduce new executor API

[Alexandre Janniaux]

On Wed, Sep 02, 2020 at 01:00:49PM +0200, Steve Lhomme wrote:
> > > > > > just for that. I don't want to add a separate "deactivate" function for
> > > > > > closing before _Delete(). Maybe the threads should continue to dequeue
> > > > > > the pending tasks until the queue is empty in case a runnable queues
> > > > > > another one after "closing"?
> > > > >
> > > > > In fact, I think it is reasonable to assert that the executor is not
> > > > > closing. It is the caller responsibility to ensure that a runnable is
> > > > > not submitted after it called vlc_executor_Delete().
> > > >
> > > > I agree, you don't want to Delete the executor while you still have
> > > > pending tasks.
> > >
> > > That means any runnable that want to launch another runnable will need to
> > > check if the executor is not canceled.
> >
> > Yes. But this is the same "component" which provides the run() function
> > and which calls vlc_executor_Delete().
>
> I don't fully understand. But that doesn't sound right. That means the
> design is too tied to very narrow specific cases. (ie not chaining tasks)

The executor can also be provided by another component owning the one
providing the run(), in which case it cannot be deleted until the
component providing the run() is also deleted.

> > > And yet if it's not canceled it may
> > > submit a task when the executor just got canceled (by another thread). And
> >
> > s/canceled/deleted/
> >
> > > you will end up in this assert.
> >
> > It is the responsibility of the caller not to submit tasks once
> > vlc_executor_Delete() is called.
>
> But there's a race condition, as explained (twice).

In my opinion, this scenario is speculative on what the programmer
does. The race condition is written by the end developer, it's not
within the executor design, since a task cannot add a new task to
the executor if there is no task running on the executor.

Regards,
--
Alexandre Janniaux
Videolabs