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

[Romain Vimont]

On Mon, Nov 23, 2020 at 10:09:37PM +0200, Rémi Denis-Courmont wrote:
> Le lundi 23 novembre 2020, 18:30:14 EET Romain Vimont a écrit :
> > There are two major (and independent) issues:
> >  1. I/O on the UI thread (#22687)
> >  2. database lock starvation while indexing
> 
> If you do a reasonable amount of I/O, doing it on the UI thread is fine. If you 
> do an insane amount of I/O, then you will slow the system down, and drain the 
> battery, no matter which thread or even process you do it from. You just 
> simply should not do that.

IMO, this is never a good idea. Any I/O latency (for whatever reason)
should never freeze the UI.

I think that it is a common practice to never execute I/O from the UI
thread. For example, this is what Android recommends:
https://developer.android.com/reference/android/os/StrictMode

> Note that even though an Android device's disk is often on flash
> memory, many devices run a filesystem on top of that memory with very
> limited concurrency. It's often the case that almost all disk accesses
> are fast, but may in individual cases be dramatically slower when
> certain I/O is happening in the background from other processes. If
> possible, it's best to assume that such things are not fast.

They also deprecated options causing queries executed on the main
thread:
https://developer.android.com/reference/android/widget/CursorAdapter#FLAG_AUTO_REQUERY

> This option is discouraged, as it results in Cursor queries being
> performed on the application's UI thread and thus can cause poor
> responsiveness or even Application Not Responding errors.

If strict mode is enabled (which is useful to find such errors), any I/O
access from the UI thread (that can be detected) will just kill the app.

On the VLC Android application, medialib queries are executed on
coroutines executed on Dispatchers.IO (i.e. not on the UI thread).

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

> And while the database might be robust enough to run from within VLC, it is 
> abundantly that some part of indexing is *not*. I guess preparsing especially.

What would you suggest?

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

Regards