From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdtVh-0006ZK-85 for guix-patches@gnu.org; Fri, 13 Jul 2018 04:33:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdtVe-0004KM-48 for guix-patches@gnu.org; Fri, 13 Jul 2018 04:33:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:49759) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fdtVd-0004JC-W6 for guix-patches@gnu.org; Fri, 13 Jul 2018 04:33:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fdtVd-0001N6-NT for guix-patches@gnu.org; Fri, 13 Jul 2018 04:33:01 -0400 Subject: [bug#32121] [PATCH 1/5] base: Compile CHECKOUT in the fiber. Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87lgain1fp.fsf@lassieur.org> <20180710230247.16639-1-clement@lassieur.org> Date: Fri, 13 Jul 2018 10:32:41 +0200 In-Reply-To: <20180710230247.16639-1-clement@lassieur.org> ("=?UTF-8?Q?Cl=C3=A9ment?= Lassieur"'s message of "Wed, 11 Jul 2018 01:02:43 +0200") Message-ID: <87in5jmt7a.fsf@gnu.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: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Cc: 32121@debbugs.gnu.org Morning! Cl=C3=A9ment Lassieur skribis: > Because it may take time and thus prevent PROCESS-SPECS to run every INTE= RVAL > seconds. > > * src/cuirass/base.scm (process-specs): move the COMPILE invocation inside > SPAWN-FIBER's thunk. Add log message. [...] > - (when compile? > - (non-blocking (compile checkout))) > - > (spawn-fiber > (lambda () > + (when compile? > + (log-message "compiling '~a' with commit ~s" name co= mmit) > + (non-blocking (compile checkout))) I think this doesn=E2=80=99t bring anything compared to the existing =E2=80=98non-blocking=E2=80=99 call. The =E2=80=98non-blocking=E2=80=99 procedure evaluates its argument in a se= parate thread; the calling fiber then =E2=80=9Cwaits=E2=80=9D for a message from t= hat thread, which it gets when the computation is over. The =E2=80=98get-message=E2=80= =99 is non-blocking though: the calling fiber is simply unscheduled until the message has arrived. Does that make sense? Ludo=E2=80=99.