From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 16:36:39 2021 Received: (at 50814) by debbugs.gnu.org; 29 Sep 2021 20:36:39 +0000 Received: from localhost ([127.0.0.1]:50381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVgJj-0006MX-0Y for submit@debbugs.gnu.org; Wed, 29 Sep 2021 16:36:39 -0400 Received: from albert.telenet-ops.be ([195.130.137.90]:40284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVgJe-0006MJ-SY for 50814@debbugs.gnu.org; Wed, 29 Sep 2021 16:36:37 -0400 Received: from ptr-bvsjgyjmffd7q9timvx.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:aaf1:9810:a0b8:a55d]) by albert.telenet-ops.be with bizsmtp id zwcY2500H0mfAB406wcYHA; Wed, 29 Sep 2021 22:36:33 +0200 Message-ID: <929da16ca45605a5bed718dea5d76db7176cf985.camel@telenet.be> Subject: Re: [bug#50814] [PATCH 4/5] guix: Prepare the UI for continuable &warning exceptions. From: Maxime Devos To: Attila Lendvai Date: Wed, 29 Sep 2021 22:36:14 +0200 In-Reply-To: References: <20210928162406.27205-1-attila@lendvai.name> <20210928162406.27205-4-attila@lendvai.name> <9c093db2d9019ef2fe9b27979a3b51848f179a3b.camel@telenet.be> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-V/4MxGN70x5Z6s40eva8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1632947793; bh=GI22FkuoFEqBMKujaz1eIZPoiDfNNAwOM3ycosZJuQ8=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=ELC9mLpRPPdOSh/RFotimQhzBrHJPPvu3F94UnWASdQEhPdHj++D645V5MsfJsVfx rfH2fD+YrBX0O8UToRpJvWFbSOA28VvywXLhSF/Vc3yUnN/pXTfrVvtnwIv9YLKN5W 2hZt0P4Zr43zk/pr/xNOYtjv9CFTtAlPFuTvareheQ7u9I8wkImdDUqI0cq/oKiGq9 Jnv1vSppUHVQMVKdhnuZnukloteVVH5NZvefpT8gzQklQPpM6go08zRES9ustJJRmH 3HPjL9xtr4CaJ9t82v2JLrvVq3aJEeIR+/jKbhNL/BcvGEkac9ncy6L9cJbPnOw/sB nitTNGO3sitvg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 50814 Cc: 50814@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-V/4MxGN70x5Z6s40eva8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Attila Lendvai schreef op wo 29-09-2021 om 14:50 [+0000]: > > Do we really need to close and open the connection again every time > > a continuation is made and resumed? This seems inefficient if a threadi= ng > > mechanism implemented by continuations is used (such as guile-fibers), > > and there are two threads (=E2=80=98fibers=E2=80=99) communicating and = waiting with/for > > each other in a loop, causing many =E2=80=98context switches=E2=80=99 (= i.e., many captured > > and resumed continuations). > >=20 > > Also note that a connection has some state: to the guix-daemon, it acts= as > > a GC root for everything built with the connection, and everything adde= d to > > the store (with add-to-store & friends) with that connection ... Simply > > reconnecting isn't sufficient. >=20 > pardon my ignorance wrt dynamic-wind and call/cc, but does that^ mean > that 1) i should simply leave the wind part of the dynamic-wind empty > and move back the open-connection call into the let... or that 2) the > entire idea of replacing the exception handler with an unwind-protect > is flawed? About 1): which 'wind part' of dynamic-wind are you referring to? The in-guard or the out-guard? If the out-guard is empty, then the reference to the old connection will be overwritten when the fiber is paused and resumed, so the old connection will eventually be GC'ed, thus the daemon forgets some GC roots, leading to a rare GC bug. If the in-guard is empty, then the after pausing the fiber and resuming it, the connection will be closed while the fiber might still need it. > if 2) then i'll try to smarten up the handler to use raise-continuable > if the exception is of type &warning. That should work. Or simpler: always use raise-continuable. > or any better ideas? Conventionally, to emit warnings, the procedure 'warning' from (guix diagnostics) is used. See e.g. (guix ci), (guix deprecation), (guix = gexp), (guix import ...), various modules under (guix scripts ...), (guix upstream= ) ... Is there any reason not to use this pre-existing procedure? Greetings, Maxime --=-V/4MxGN70x5Z6s40eva8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYVTOPhccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7kuAAQCi8x1NRBBbbxHyFXbLl61sG0ss PuW6GDFBYCce02bXJQD+KB6Al9UEmjJL54d0ZSqL5GHacy/U1mFVBHwJVrwxFQA= =C9qm -----END PGP SIGNATURE----- --=-V/4MxGN70x5Z6s40eva8--