From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJozS-0006SD-78 for guix-patches@gnu.org; Mon, 05 Nov 2018 19:13:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJozO-0008U9-RC for guix-patches@gnu.org; Mon, 05 Nov 2018 19:13:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:59817) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJozO-0008Ti-MA for guix-patches@gnu.org; Mon, 05 Nov 2018 19:13:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gJozO-0001Qi-Ee for guix-patches@gnu.org; Mon, 05 Nov 2018 19:13:02 -0500 Subject: [bug#33210] Cuirass: Use a SQLite in single-thread mode Resent-Message-ID: Date: Tue, 6 Nov 2018 01:11:54 +0100 From: Danny Milosavljevic Message-ID: <20181106011154.3f235763@scratchpost.org> In-Reply-To: <87ftwgq7da.fsf@lassieur.org> References: <87a7mvqikl.fsf@lassieur.org> <871s80o2zc.fsf@gnu.org> <87ftwgq7da.fsf@lassieur.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/u0q.3rbDce6kZRVK/C3r2wj"; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Cc: 33210@debbugs.gnu.org --Sig_/u0q.3rbDce6kZRVK/C3r2wj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Cl=C3=A9ment, > I haven't done any measurement yet, but according to the SQLite > documentation: >=20 > Setting -DSQLITE_THREADSAFE=3D0 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. >=20 > So even if the optimization is small, it's the option that has the > biggest impact on performance. >=20 > > We could do it, but IMO that should be a last resort because I=E2=80=99= d expect > > it to be a micro-optimization. =20 >=20 > 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. --Sig_/u0q.3rbDce6kZRVK/C3r2wj Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlvg3EoACgkQ5xo1VCww uqVy8AgAjYGaTge0p2rpUl6eK31W3VZQ9C5qRSnFyDrv07W3q4X/5TGNrY3GKKKQ uwdq2eODz2Ro4HHI/4oclNPIvwhssECdQHlDEYPymwcK41AtBixiE+IpzaPgyya7 hY394Q/h45SXK4+ZnnKVzjhpP+3AShFP1wvvCifZCW4JilaAOSpIaqlbLD9YymwI C+OhM6hZFBaI8AjnzG9fxc2ujBozFVW8i94Y7vykTJgTc4ua//4SgY1jogYgsEQf elUwAvTSA7C4ClSoIWZ96JS2gmCssufR9e585yxZlf3prTXrt38K6cPPGVmg8dHC TrHidrTNtBL+FD1PSZOyLoSSxc09rQ== =CkT6 -----END PGP SIGNATURE----- --Sig_/u0q.3rbDce6kZRVK/C3r2wj--