|
|
In today's chapter of gratuituous rewrites. The instigator of this
rewrite is vala's bug https://bugzilla.gnome.org/show_bug.cgi?id=789249.
One might argue that bugs are bugs and eventually get fixed, but there's
two things that make me think it won't happen soon:
- Vala behavior of possibly iterating the main loop from the async task
until the task is complete is very much deliberate in order to support
the Generator pattern without a main loop, as seen at:
https://wiki.gnome.org/Projects/Vala/AsyncSamples#Generator_example
- OTOH, glib docs specify that a GAsyncReadyCallback must happen at a
later iteration of the main context, presumably to ensure the task
is not finished before the async function dispatching the task returns.
This is precisely what trips Vala into starting the same task again.
I don't see either changing anytime soon, and in the mean time Tracker
is largely affected by it, both in perceived bugs (All those nie:url
constraint warnings out of the blue had a reason, this) and in real bugs
(It's sometimes attempting to insert things twice, and it may even succeed
if the query does not break any cardinality/unique constraints). This
affects Tracker in too fundamental ways to just shrug it away, unlike the
Vala code this C/glib code works just as it looks.
Now about the code... It's a pretty boring rewrite, there's a thread pool
to dispatch select queries, and a single exclusive thread to handle updates.
The WAL hook can possibly use an additional thread to perform non-blocking
writes. All very much alike the older code.
Future commits will make tracker-store use this connection implementation,
so there's only this piece of code handling SPARQL updates.
|
