From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: bug#30644: Cuirass runs out of build users Date: Thu, 8 Mar 2018 00:01:11 +0100 Message-ID: <20180308000111.77cce7d6@scratchpost.org> References: <20180228090714.GA1845@jurong> <20180302140833.GB3213@macbook41> <20180305090256.GA9171@jurong> <20180305155351.GA6054@jurong> <87efkvpl8f.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/2tz0C+390zFpYhFyObboDrY"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eti4T-0003YN-Vo for bug-guix@gnu.org; Wed, 07 Mar 2018 18:02:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eti4Q-00035C-T4 for bug-guix@gnu.org; Wed, 07 Mar 2018 18:02:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:42084) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eti4Q-000357-P6 for bug-guix@gnu.org; Wed, 07 Mar 2018 18:02:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eti4Q-0006MD-Df for bug-guix@gnu.org; Wed, 07 Mar 2018 18:02:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87efkvpl8f.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 30644@debbugs.gnu.org --Sig_/2tz0C+390zFpYhFyObboDrY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Ludo, > > 69:18 2 (%sqlite-exec _ _ . _) > > In ice-9/eval.scm: > > 293:34 1 (_ #(#(# #< ?))) > > 619:8 0 (_ #(#(#(#(# #) #) 5) 5)) > > ice-9/eval.scm:619:8: Throw to key `sqlite-error' with args `(#f 5 "dat= abase is locked")'. =20 >=20 > Bah. :-/ sqlite3.h contains quite nice documentation about this case: /* ** CAPI3REF: Unlock Notification ** METHOD: sqlite3 ** ** ^When running in shared-cache mode, a database operation may fail with ** an [SQLITE_LOCKED] error if the required locks on the shared-cache or ** individual tables within the shared-cache cannot be obtained. See ** [SQLite Shared-Cache Mode] for a description of shared-cache locking.=20 ** ^This API may be used to register a callback that SQLite will invoke=20 ** when the connection currently holding the required lock relinquishes it. ** ^This API is only available if the library was compiled with the ** [SQLITE_ENABLE_UNLOCK_NOTIFY] C-preprocessor symbol defined. ** ** See Also: [Using the SQLite Unlock Notification Feature]. ** ** ^Shared-cache locks are released when a database connection concludes ** its current transaction, either by committing it or rolling it back.=20 ** ** ^When a connection (known as the blocked connection) fails to obtain a ** shared-cache lock and SQLITE_LOCKED is returned to the caller, the ** identity of the database connection (the blocking connection) that ** has locked the required resource is stored internally. ^After an=20 ** application receives an SQLITE_LOCKED error, it may call the ** sqlite3_unlock_notify() method with the blocked connection handle as=20 ** the first argument to register for a callback that will be invoked ** when the blocking connections current transaction is concluded. ^The ** callback is invoked from within the [sqlite3_step] or [sqlite3_close] ** call that concludes the blocking connections transaction. ** ** ^(If sqlite3_unlock_notify() is called in a multi-threaded application, ** there is a chance that the blocking connection will have already ** concluded its transaction by the time sqlite3_unlock_notify() is invoked. ** If this happens, then the specified callback is invoked immediately, ** from within the call to sqlite3_unlock_notify().)^ ** ** ^If the blocked connection is attempting to obtain a write-lock on a ** shared-cache table, and more than one other connection currently holds ** a read-lock on the same table, then SQLite arbitrarily selects one of=20 ** the other connections to use as the blocking connection. ** ** ^(There may be at most one unlock-notify callback registered by a=20 ** blocked connection. If sqlite3_unlock_notify() is called when the ** blocked connection already has a registered unlock-notify callback, ** then the new callback replaces the old.)^ ^If sqlite3_unlock_notify() is ** called with a NULL pointer as its second argument, then any existing ** unlock-notify callback is canceled. ^The blocked connections=20 ** unlock-notify callback may also be canceled by closing the blocked ** connection using [sqlite3_close()]. ** ** The unlock-notify callback is not reentrant. If an application invokes ** any sqlite3_xxx API functions from within an unlock-notify callback, a ** crash or deadlock may be the result. ** ** ^Unless deadlock is detected (see below), sqlite3_unlock_notify() always ** returns SQLITE_OK. ** ... */ ... ** When a call to [sqlite3_step()] returns SQLITE_LOCKED, it is almost=20 ** always appropriate to call sqlite3_unlock_notify(). There is however, ** one exception. When executing a "DROP TABLE" or "DROP INDEX" statement, ** SQLite checks if there are any currently executing SELECT statements ** that belong to the same connection. If there are, SQLITE_LOCKED is ** returned. In this case there is no "blocking connection", so invoking ** sqlite3_unlock_notify() results in the unlock-notify callback being ** invoked immediately. If the application then re-attempts the "DROP TABLE" ** or "DROP INDEX" query, an infinite loop might be the result. ** ** One way around this problem is to check the extended error code returned ** by an sqlite3_step() call. ^(If there is a blocking connection, then the ** extended error code is set to SQLITE_LOCKED_SHAREDCACHE. Otherwise, in ** the special "DROP TABLE/INDEX" case, the extended error code is just=20 ** SQLITE_LOCKED.)^ ... --Sig_/2tz0C+390zFpYhFyObboDrY Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlqgbzcACgkQ5xo1VCww uqUqvwf+K8RcWUlgI69jHswsWcdxop5DZLO+fmrrke5oucbVwwUK/EHOnIOP1mCF SiipcVmrQiZEaRqztlo4UVqxgCmzsmnj01pkceQjp3zB/v/inIRdTQtXyUOslC83 DmVfkbHJc0rfpK9kH16/XTqjOgwPZeS3EULuEMaUc0RwwX5lBbQWQAL2UXBoJs7x 5Fa4E8dsdK9nV6g5dgyM/0mMtuk1PFzc75HLErmCaYsuq9+dtB1BpKWHNRIpgWzQ BFsWbGBxT7VuIq1/7kE+IGrpY9R2LKD9iE06RVr6MpUOGdw/VMd+8JDPnrzl//LW xf9eN4pSohqeNKS8z4hy79OBeovaZQ== =k6Xf -----END PGP SIGNATURE----- --Sig_/2tz0C+390zFpYhFyObboDrY--