[vlc-devel] [PATCH v4 2/3] Update media tree on browsing/preparsing
Rémi Denis-Courmont
remi at remlab.net
Tue Jul 10 17:37:26 CEST 2018
Le tiistaina 10. heinäkuuta 2018, 16.27.56 EEST Romain Vimont a écrit :
> > On the one hand, in vlc_media_tree_Remove(), the media tree lock is taken
> > first, then input item events are unregistering, taking the event manager
> > lock of the respective input item. On the other hand, in input item event
> > callbacks, the media tree gets locked while the event manager lock is
> > held.
> Wow, that's very true.
>
> There's the same problem in the current code in the playlist:
Of course there is. That is one of the three (known to me) outstanding design
bugs with the current playlist/SD.
(The other two are: 1) ToCToU when checking if SD is loaded. 2) String
comparison to identify SD.)
> We want to attach/detach callbacks when we add/remove an item to the
> tree, and we want to modify the tree when the callback is triggered.
Well yes. Neither of the "obvious" ways to fix a lock inversion are applicable
here. You cannot unify the lock ordering because it leads to a catch-22.
You can neither merge the two locks, because it is not two locks, but one lock
on one side (MT) and one entire set of locks on the other side (II's EM).
> For now, I can't think of an elegant+correct solution. Do you have any
> suggestions?
Altogether avoid libvlc_MediaSubItemAdded and libvlc_MediaSubItemTreeAdded, or
really any input item event, in the context of the media tree.
SD already dutifully avoids those broken-by-design events. The remaining
outstanding fault lies in ES output calling input_item_node_PostAndDelete() on
behalf of playlist demuxers.
--
Реми Дёни-Курмон
http://www.remlab.net/
More information about the vlc-devel
mailing list