[vlc-devel] [RFC 1/2] executor: introduce new executor API

[Rémi Denis-Courmont]

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 
obvious...

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