[vlc-devel] VLC architecture bash
rem at videolan.org
Sat Sep 20 15:29:14 CEST 2008
Le samedi 20 septembre 2008 16:02:04 Derk-Jan Hartman, vous avez écrit :
> Each object has a common part and an object specific part.
> The common part holds references to it''s children objects, parent and
> the root. This creates a type of Tree of objects each one responsible
> for its own children.
That really does not address what the use of the tree is - apart from making
reference counting more crash- or deadlock-prone.
> It also holds variables,
Which sucks, as there is no way to get the list of potential variables and
values, contrary to a structure or something.
> and flags for various states (dead/dying),
The only one being actually used is b_die, which is not even thread-safe.
Besides, it only makes sense per-thread, not per object.
> a name for the object,
Error prone. If the user uses a "special" object name (e.g. "qt4") for its
object, it can crash the Qt4 embedded window for instance.
> object type id (so we know what type of object
> specific data is stored after the common part),
Pointless. So you know the object type, so what? Seldom can you use objects of
different types (decoder and packetizer are the only case I know).
Historically, this has been abused by interfaces to enumerate objects and
start using the pf_* callbacks (e.g. p_access->pf_control) out of nowhere -
and boom, that broke thread-safety.
> even a thread reference if needed.
Harmful, as we have learnt during 0.9 development. It creates inconsistent
behavior, especially w.r.t. to b_die when different instance of a single
object type may or may not use threads (e.g. access, demuxes...).
It also goes the against the small/simple is beautiful principle. Objects do
way too many unrelated things. There comes for instance, the mixup
between "attached means findable, initialized and ready for cross-thread
interactions", and "attached means inherits configuration variables from
And why oh why are module_t derived vlc_object_t: no threads, no variables, no
> > This allows us to re-use code that we use much throughout the entire
> > library, without using C++
You don't seriously believe that the horrible vlc_object_t is REQUIRED to have
re-usable code, do you???
> A variable can inherit it's value from parent objects that have the
> same named variable, or from a configuration option with the same
And then the parent is destroyed asynchronously, and inheritance breaks.
> A variable can have Callbacks that are triggered when it's value
> is changed, as well as value limits, or lists of allowed named values.
And almost every callback forgets about proper locking and event handling.
Oh, and the callback loops too!
> All in all it's very flexible if it works.
Do you really think that mixing all kind of loosely or unrelated features into
a single all-in-one objects increases flexibility? Come on...
More information about the vlc-devel