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

[Alexandre Janniaux]

On Wed, Sep 02, 2020 at 12:37:18PM +0200, Thomas Guillem wrote:
>
>
> On Wed, Sep 2, 2020, at 11:47, Romain Vimont wrote:
> > On Wed, Sep 02, 2020 at 11:43:54AM +0200, Steve Lhomme wrote:
> > > On 2020-09-02 11:38, Alexandre Janniaux wrote:
> > > > Hi,
> > > >
> > > > On Wed, Sep 02, 2020 at 11:24:32AM +0200, Romain Vimont wrote:
> > > > > On Wed, Sep 02, 2020 at 10:34:28AM +0200, Romain Vimont wrote:
> > > > > > On Wed, Sep 02, 2020 at 08:13:15AM +0200, Steve Lhomme wrote:
> > > > > > > On 2020-09-01 18:13, Romain Vimont wrote:
> > > > > > > > +     *
> > > > > > > > +     * \param userdata the userdata provided to vlc_executor_Submit()
> > > > > > > > +     */
> > > > > > > > +    void (*run)(void *userdata);
> > > > > > >
> > > > > > > Since the userdata is also part of the vlc_runnable, you may pass the
> > > > > > > vlc_runnable instead of the userdata. It allows more flexibilty in the
> > > > > > > future (for example if you want to do actions on the runnable, like run it
> > > > > > > again).
> > > > > >
> > > > > > Good point. But now I realize that running a runnable again may cause
> > > > > > issues in regards to cancelation/deletion.
> > > > >
> > > > > In fact, my preference is to pass "userdata" directly (not the
> > > > > vlc_runnable instance), because this is typically what the user directly
> > > > > need.
> > > > >
> > > > > In case the very same runnable must be resubmitted (I would recommend
> > > > > against it, and create a new runnable instead, otherwise it may be more
> > > > > difficult to handle cancelation correctly), the runnable instance is
> > > > > typically accessible from the user-provided structure hidden behind the
> > > > > void*.
> > > >
> > > > I agree, the task can queue a newer task while keeping the same state.
> > >
> > > By the way, to be able to submit another runnable, you need to have access
> > > to the executor. You may pass it in the run() callback.
> >
> > The user references whatever it wants in its userdata structure. If it
> > needs the executor, it will reference it from there, otherwise it won't.
>
> It could mean a new alloc just for that case. If the userdata is a pointer to a public API structure for example that the owner doesn't control.

Why would it be a new alloc?