[vlc-devel] [RFC PATCH 1/8] contrib: Update & reactivate sqlite
hugo at beauzee.fr
Tue Jun 26 13:45:51 CEST 2018
On Tue, Jun 26, 2018, at 4:29 AM, Rémi Denis-Courmont wrote:
> Hmm, my understanding of SQLite locking is probably out of date, and it
> seems that the analysis depends on the SQLite method used (e.g. WAL).
> But in any case, using SQLite, or really any read/write storage in VLC
> poses certain potential problems:
> - users with network mounted home directories
I suppose if that folder is not available the medialibrary initialization would fail, and that case must be handled gracefully (ie. not like the current temporary initialization) I suppose that would be similar to launching VLC with --no-media-library.
Should the folder be unmounted during runtime, the medialibrary can fail gracefully as well, and would restore any potential write operation during startup.
> - VLC crashing during an update
My understanding is that SQLite's journal covers this
> - VLC freezing during an update
I'm not sure there's something to handle there, as far as the medialibrary is concerned
> - writes in one VLC process desynching data in another VLC process (e.g.
> deleting or updating an entry)
That could be an issue indeed. SQLite would return SQLITE_BUSY, it's up to us to determine if we want to retry, and if so for how long, or if we want to do something a bit more clever by communicating across VLC processes, or limitating the ML instances to a single VLC process
> - storage space accumulation / check-pointing
I don't think that's something specific to sqlite or any database for that matter.
> - database layout changes upon software updates
This is handled in the medialibrary and tested by quite a few VLC for Android updates
> - I/O error handling
In case of reading, we retry for some time and eventually give up. For writing, it's a bit trickier and depends on the failing write. We handle quite a few cases already, but I can't swear all of them are. The code infrastructure to handle such errors is present, for what it's worth, and at the end of the day, I'm not sure we can do much if a write to disk fails, except for not crashing & retrying later
> SQLite won't do magic. It's unlikely that it effectively addresses all
> the issues.
> So far the problem only exists for the configuration and the plugins
> cache. But they are much easier to handle, as we treat them as "all or
> Le 26 juin 2018 09:58:23 GMT+01:00, "Hugo Beauzée-Luyssen"
> <hugo at beauzee.fr> a écrit :
> >On Tue, Jun 26, 2018, at 1:23 AM, Rémi Denis-Courmont wrote:
> >> Le lundi 25 juin 2018, 11:09:59 EEST Hugo Beauzée-Luyssen a écrit :
> >> > ---
> >> > contrib/src/sqlite/SHA512SUMS | 2 +-
> >> > contrib/src/sqlite/rules.mak | 12 ++++++------
> >> > 2 files changed, 7 insertions(+), 7 deletions(-)
> >> AFAIR, SQLite cannot, by design, be used in multiple processes.
> >AFAIK it can, although multiple processes using the same database would
> >lock it during write operations.
> >But in this specific case, I do not see an issue for VLC's use case
> >> With that restriction, there may be some corner case uses for SQLite
> >that do
> >> not exist yet - but hardly a media library storage back-end.
> > Hugo Beauzée-Luyssen
> > hugo at beauzee.fr
> >vlc-devel mailing list
> >To unsubscribe or modify your subscription options:
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser
> ma brièveté.
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
hugo at beauzee.fr
More information about the vlc-devel