Some database operations do need transactional semantics for their whole
operation (i.e. if you were to stop it half-way and commit to allow other
readers/writers to process) -- for example shuffling a playlist. In this
case multiple writers could lead to data corruption races. Beyond this,
today's approach of doing some operations on the GUI thread blocks Qt from
processing events. This has implications on Mixxx's responsiveness because
things like waveform rendering cannot do work while the Qt main thread is
blocked attempting to read/write from the database. As Daniel mentioned on
the waveform thread yesterday, sometimes normal, small library operations
hog the main thread for up to 20ms. This is enough to cause a dropped frame
when rendering the waveform at a reasonable FPS. It also increases the
overall latency of the ControlObject system when the control events are
proxied through the Qt event queue. So database queries on the main thread
can add to the latency of pressing a button / slider / knob on the GUI.
These are all motivating factors for moving database queries to a thread.
cheers,
RJ
On Mon, Apr 29, 2013 at 9:45 AM, Steven Boswell II <[email protected]>wrote:
> Correct me if I'm wrong, but wouldn't a functional "non-blocking database
> access" implementation be a lot simpler than what's been discussed here?
>
> The issue is that some database operations are interruptible, although
> it's more efficient for them to not be done incrementally. Library-rescan,
> and playlist/crate import where the imported playlist-file has a lot of
> tracks that aren't already in the database, seem to be the two biggest
> cases, and both involve adding lots of entries to the "library" table.
>
> It seems to be that implementing this feature boils down to this:
>
> 1) Clean up the src/library/dao layer so that each DAO object only
> accesses/modifies one table directly.
> 2) Any table that can remain locked for a long time (just "library"?)
> gains some internal logic that allows writers to run unimpeded unless there
> are readers, in which case the batch-write operation is committed, all the
> readers are allowed to do their thing, then the batch-write operation
> continues.
>
> This is much simpler than a separate thread, and accomplishes the same
> thing.
>
> Steven Boswell
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> _______________________________________________
> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> http://mixxx.org
>
>
> Mixxx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
