[bug#33210] Cuirass: Use a SQLite in single-thread mode

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

Hi Clément,

> I haven't done any measurement yet, but according to the SQLite
> documentation:
> 
>     Setting -DSQLITE_THREADSAFE=0 causes all of the mutex and
>     thread-safety logic in SQLite to be omitted. This is the single
>     compile-time option that makes the most difference in optimizing the
>     performance of SQLite.
> 
> So even if the optimization is small, it's the option that has the
> biggest impact on performance.
> 
> > We could do it, but IMO that should be a last resort because I’d expect
> > it to be a micro-optimization.  
> 
> Lots of micro-optimizations lead to an overall faster application ;-).
> And this one doesn't make the code more complicated.  To me it's just a
> bonus.

Keep in mind that if we want consistent views via the web interface,
the cuirass evaluator has to use its own connection independent of the
web interface (so that the web interface doesn't see half-finished stuff).
If that's still possible after that then fine.

Right now, as I mentioned before, it can happen that you request a certain
filter when requesting something from the web and the result will actually
contain data that does not match the filter.  What happened is that the
data in the transaction got changed before we returned it but after the
first query ran.

This is not supposed to happen in relational database systems.  The reason
why it happens here is because we use the same transaction (session) for
both the updates done by the evaluator and the queries done by the web
interface.  It would be much better if the queries by the web interface
had their own transaction.  It was fine before but in some refactoring,
"evaluate" ceased to be an external program and I didn't notice what
happened to it.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]