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

[Romain Vimont]

On Tue, Nov 24, 2020 at 05:23:55PM +0200, Rémi Denis-Courmont wrote:
> Le lundi 23 novembre 2020, 22:28:54 EET Romain Vimont a écrit :
> > IMO, this is never a good idea. Any I/O latency (for whatever reason)
> > should never freeze the UI.
> 
> The eighties called and they want their real mode back. With demand paging, 
> transparent swap and what-not, you cannot prevent I/O on the UI thread (or 
> almost any thread really).

OK, my statement was probably too general.

But this definitely includes "do not execute SQL queries from the UI
thread".

> > I think that it is a common practice to never execute I/O from the UI
> > thread.
> 
> And I am pretty damn sure that it is uncommon, or more accurately, never done 
> except on low-end embedded devices.

I don't have statistics. I know that I/O on main thread is highly
discouraged on Android (because it makes the applications unresponsive).

It seems that Chrome/Chromium also recommends to do so:
https://chromium.googlesource.com/chromium/src/+/master/docs/threading_and_tasks.md#Keeping-the-Browser-Responsive

Their example refers to loading items from disk, which is exactly what
we do (via SQLite):

    // GetHistoryItemsFromDisk() may block for a long time.

> > I think we should follow the same principle in the Qt interface.
> 
> I disagree.

I can't agree that this is ok to execute SQL queries (which accesses a
file on the disk) on the main thread.

Moreover, in addition to I/O delays, there is a RW-lock on the database.

> That's just vain as it won't achieve the goal anyway.

I disagree, this makes the app more responsive.

> And on a 
> systematic basis, it would make the code insanely complex and buggy with 
> events going back and forth - all for nothing.

Yes, of course it adds complexity. But not "for nothing".

> > 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.

Instead, the "UI queries" should get absolute priority over "indexing
queries" (or something like that).

Regards