[vlc-devel] [RFC 1/2] executor: introduce new executor API
rom1v at videolabs.io
Thu Aug 27 14:59:54 CEST 2020
On Wed, Aug 26, 2020 at 11:27:59PM +0300, Rémi Denis-Courmont wrote:
> Le keskiviikkona 26. elokuuta 2020, 23.11.08 EEST Romain Vimont a écrit :
> > > > + * int ret = vlc_executor_Submit(executor, &runnable, str, NULL,
> > > > 0);
> > > > + * assert(ret == VLC_SUCCESS);
> > > > + * }
> > > > + * \endcode
> > > >
> > > > +VLC_API int
> > > > +vlc_executor_Submit(vlc_executor_t *executor,
> > > > + const struct vlc_runnable *runnable, void
> > > > *userdata,
> > > > + void *id, vlc_tick_t timeout);
> > >
> > > Type name for works and workers really ought to be in the same semantic
> > > field IMO.
> > (the naming was inpired from ExecutorService in Java, but Executor is
> > quite "standard" in other languages too.)
> > > It is unlikely that callers will (or even should have to) handle errors
> > > well at this point.
> > The error handling is simple here:
> > - VLC_SUCCESS: the runnable is submitted
> > - other: there was an error, the runnable will not be executed
> Error handling is almost always "simple", meaning binary, by that definition.
> The point is that it is an inconvenient (and potentially impossible) state for
> the caller to handle errors. We don't normally allow thread functions to fail
> except at allocation/creation time (or not even).
Since _Submit() allocates and may create a thread, it seems logical to
me to report an error.
What would you suggest? I think that trying to not create/allocate here
will not lead to a better solution.
> And thus this also breaks the principle of least surprise. If I've allocated a
> worker and a work succesfully, why should it fail to queue... Of course, if
> you look at the implementation, there are reasons. But that's not externally
More information about the vlc-devel