[vlc-devel] [PATCH 5/5] core: first cleaning of input_thread_t variables/event
remi at remlab.net
Wed Jul 11 17:33:12 CEST 2018
Le keskiviikkona 11. heinäkuuta 2018, 10.22.16 EEST Thomas Guillem a écrit :
> > The internal input controls from input_control_e are (currently) needed
> > for
> > message passing to the input thread. But the external controls from
> > input_query_e do not seem to have any real motivation.
> I have a question for the distant future where the input manager/player is
> controlled via IPC for the sandbox: Will it make easier to have only one
> control function ?
No. First, the proposed union does and needs to contain pointers, so it cannot
be just slapped over an IPC. And then, passing structures through trust
boundaries is a Bad Idea, e.g.:
> Is there a generic way to serialize va_args ?
The number and types of variadic arguments must be known at compilation time.
There are no ways to synthetize a variadic function call at run-time, except
maybe (?) through FFI.
> I guess no since you need the event type in order to know the size and the
> number of args.
> BTW, I put some thought on input_thread_t vs input_manager_t:
> I want to remove all getters from the input_thread_t.
> The only way to know the current state (pos/time/length...) is to listen to
> all callbacks from the beginning. This is necessarily the case since you
> must add a callback when you create the object.
Uh? You can have a callback to notify rate change, pause change, and updates
to clock coefficients. But you cannot really have callbacks for time and
position, since in general, they keep changing. You are not going to invoke
the time callback every VLC tick...
In fact, the current callbacks are already notoriously broken with some
demuxers (because they don't update "often enough" to somebody's taste).
> Then the input manager (or the playlist with the legacy var foo) will save
> the input_thread_t internal state (by listening to the events). Therefore,
> any clients (qt or http intf for example) that query an input will be able
> to get the initial state via this input manager. I thought about triggering
> events in order to give the initial state when a client is first
> registering to events (via vlc_input_manager_AddListener).
More information about the vlc-devel