From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK298-0001oN-Qh for guix-patches@gnu.org; Tue, 06 Nov 2018 09:16:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gK21S-0006N6-OI for guix-patches@gnu.org; Tue, 06 Nov 2018 09:08:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:60139) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gK21S-0006Mu-KV for guix-patches@gnu.org; Tue, 06 Nov 2018 09:08:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gK21S-00078M-CA for guix-patches@gnu.org; Tue, 06 Nov 2018 09:08:02 -0500 Subject: [bug#33210] Cuirass: Use a SQLite in single-thread mode Resent-Message-ID: References: <87a7mvqikl.fsf@lassieur.org> <871s80o2zc.fsf@gnu.org> <87ftwgq7da.fsf@lassieur.org> <20181106011154.3f235763@scratchpost.org> <87efbzqbb0.fsf@lassieur.org> <20181106122036.25bad548@scratchpost.org> From: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur In-reply-to: <20181106122036.25bad548@scratchpost.org> Date: Tue, 06 Nov 2018 15:07:40 +0100 Message-ID: <875zxa5mfn.fsf@lassieur.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Danny Milosavljevic Cc: 33210@debbugs.gnu.org Hey Danny, Danny Milosavljevic writes: > Hi Cl=C3=A9ment, > > On Tue, 06 Nov 2018 01:50:11 +0100 > Cl=C3=A9ment Lassieur wrote: > >> > This is not supposed to happen in relational database systems. The re= ason >> > why it happens here is because we use the same transaction (session) f= or >> > 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.=20=20 >>=20 >> Yes, I know, but I remember that I told you[1] that there was an easy >> (one line) fix for this. :-) > > That would really only be a workaround (arguably still better than what we > have now - which is basically you ask for a banana and I give you an apple > - what if other procedures in cuirass assume it's a banana? :) ). > > We would be doing the work that SQLite would have done, but we'd do it in= a bad > way (by blocking everyone else). > > It's not really useful to undo all the progress relational databases have= made. > > If we had multiple transactions in progress touching the same row, SQLite= would > use MVCC to hold diverging copies of the same row at the same time, block= ing > nobody. It blocks everyone indeed, because we take care of the scheduling in a rather basic way. But if I understand correctly, the overall spent time is more or less the same: only the order of the requests differs. There is an essential difference however: if we take care of the scheduling, we won't have SQLITE_BUSY blocking the Fibers scheduler all the time. And blocking the Fibers scheduler has an impact on all other possibly unrelated Fibers clients. When guile-sqlite3 handles SQLITE_BUSY correctly, I'll be happy to switch back to a multi-threading SQLite. While waiting for it, I believe our users want a fast Cuirass, and I'd like the time spent in the Fibers scheduler to be balanced by removing the SQLite now useless mutexes. Does that make sense? Cl=C3=A9ment