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

[Rémi Denis-Courmont]

Le perjantaina 28. elokuuta 2020, 19.50.34 EEST Romain Vimont a écrit :
> 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);
> 
> ?

You can either do that, or combine init and submission, I think.

-- 
Реми Дёни-Курмон
http://www.remlab.net/