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

[Romain Vimont]

On Fri, Aug 28, 2020 at 07:41:17PM +0300, Rémi Denis-Courmont wrote:
> Le perjantaina 28. elokuuta 2020, 19.28.56 EEST Romain Vimont a écrit :
> > > > So if the
> > > > caller just provides a runnable (a run callback) and a userdata pointer,
> > > > then the executor must be able to allocate something on _Submit() (so it
> > > > may fail) or limit the queue size (so it may also fail). Unless the
> > > > client also provides a structure with some data private to the executor
> > > > (e.g. a vlc_list node), but that looks ugly.
> > > > 
> > > > Moreover, if we don't want to spawn all the max_threads threads on
> > > > creation, we would like to spawn a thread as necessary on _Submit() (so
> > > > that may fail). IMO, it's not a problem that _Submit() returns an error
> > > > code.
> > > 
> > > Only one thread is needed to ensure that neither errors nor deadlocks ever
> > > happen. If non-first threads fail to be created dynamically, you can
> > > always
> > > fail safe to fewer threads than the maximum.
> > 
> > OK for thread creation, but what do you suggest to queue the submitted
> > runnables?
> 
> If you expose the layout of the runnable (not the runner) to users, they can 
> nest and allocate it in their private data. That's what we already do for 
> pretty much every thread synchronisation object.
> 
> And what's it anyway? A list node entry, callback pointer and optionally an 
> opaque data pointer.

OK, so you suggest to expose the vlc_list node in the public
vlc_runnable structure?

Something like:

    struct vlc_runnable {
        void (*run)(void *userdata);
        void *userdata;
        struct vlc_list node;
    };

with

    void vlc_executor_Submit(vlc_executor_t *executor,
                             const struct vlc_runnable *runnable);

?