[vlc-devel] [RFC 1/2] executor: introduce new executor API
remi at remlab.net
Wed Aug 26 22:27:59 CEST 2020
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).
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