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

[Rémi Denis-Courmont]

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.

-- 
レミ・デニ-クールモン
http://www.remlab.net/