[vlc-devel] Playlist synchronization with multiple interfaces

[Romain Vimont]

Hi,

I would like to share some reflections about the playlist, and how to
handle possible inconsistent states between the core and the UI.

The interface maintains a copy of the list of items present in the
playlist (which "lives" in the interface thread).

Suppose the user selects items 10 to 20, and drag&drop to move them to
index 42: once the user "drops" the items, we take the playlist lock,
and want to apply these changes to the core playlist. The problem is,
before we successfully acquired the lock, another interface may have
changed the list (e.g. cleared it, or removed items 5 to 15, or moved
item at index 42 to index 10). Therefore, we cannot really apply the
"move" request as is, because it was created from a previous state
(possibly "incompatible", with conflicting changes).

To resolve the problem, we can try to make the move-request fit the new
playlist state (best-effort). This implies that we cannot use indices
(they may have changed), so we need to lookup every item (some of them
may have been removed). For moving items, we would not "move items 10-20
to 42", but "move these items to after the item that happened to be at
index 41" (if item 41 has been removed when we try to apply the move,
there's a conflict, never mind, we throw the move-request; if some items
have been removed, the move-request is partially applied).

It is not too problematic, since in practice it is very rare to modify
the playlist from several interfaces. This solution just requires to
find/lookup items in the playlist, instead of just using their (known,
but outdated) index. This is what VLC currently does (IIUC).

Another alternative would be to reject a request based on an older
state. For example, the playlist could increment a "version" integer on
every write operation, and every write-operation would pass its current
"version" from which the changes are applied. Since the conflicts are
expected to be rare, the version would typically almost always match.
That way, we can request operations from their indices ("remove item at
index 42", "insert this item at index 10"): if the version matches, then
the index is necessarily correct. Also, operations may not be "partially
applied". The big drawback is that this "versioning" would need to be
exposed to the clients of the API.

I would like to know your thoughts about this.

Thank you