[vlc-devel] [PATCH 00/13] Execute medialib queries out of the UI thread

Alexandre Janniaux ajanni at videolabs.io
Wed Nov 25 10:35:29 CET 2020


Hi,

On Tue, Nov 24, 2020 at 08:45:20PM +0200, Rémi Denis-Courmont wrote:
> Le mardi 24 novembre 2020, 18:52:28 EET Romain Vimont a écrit :
> > > > Btw, even if indexing/preparsing is done from a separate process, it's
> > > > still the same database with the same lock (so this would still cause
> > > > delays).
> > >
> > > No. Your design is pretty broken if the DB lock is held while preparsing.
> >
> > AFAIU (I did not investigated in detail), during indexing there are a
> > lot of successive writes (enqueued), and a single "row count" or "get
> > item at" is executed after the write queries posted before.
>
> Point is that the preparser  should not be holding the DB lock while
> preparsing, but only while storing the results of a finished preparse. So then
> preparsing I/O won't (indirectly) block DB readers anyway.

Romain's point might have been confusing here:

On Mon, Nov 23, 2020 at 05:30:14PM +0100, Romain Vimont wrote:
> Even if the average query duration might sometimes be acceptable (at least with
> an SSD), there may be I/O delay peaks making the UI laggy. Such I/O latency
> should never freeze the whole application. Therefore, VLC should never execute
> I/O (in particular database queries) from the UI thread. The problem is made
> obvious when the database lock is held for tens of seconds for other queries.

The reality is not that preparser is holding the DB lock, but
at some point the preparser results must be written to the
database and the starvation is to be understood as a classical
reader/writer starvation, from what I understood of the issue.

I don't think a shot in the dark can help to fix it. Romain did
measurements and his patchset is effectively reducing a lot of
UI lags, so LGTM for me.

Regards,
--
Alexandre Janniaux
Videolabs


More information about the vlc-devel mailing list