From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdwbJ-0007Nc-BK for guix-patches@gnu.org; Fri, 13 Jul 2018 07:51:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdwbG-0005SJ-9b for guix-patches@gnu.org; Fri, 13 Jul 2018 07:51:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:49842) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fdwbG-0005SD-4t for guix-patches@gnu.org; Fri, 13 Jul 2018 07:51:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fdwbF-0001f8-U5 for guix-patches@gnu.org; Fri, 13 Jul 2018 07:51: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> <87in5jmt7a.fsf@gnu.org> <87y3ef1pmo.fsf@lassieur.org> Date: Fri, 13 Jul 2018 13:50:21 +0200 In-Reply-To: <87y3ef1pmo.fsf@lassieur.org> ("=?UTF-8?Q?Cl=C3=A9ment?= Lassieur"'s message of "Fri, 13 Jul 2018 10:55:27 +0200") Message-ID: <87fu0njqwy.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 Cl=C3=A9ment Lassieur skribis: > Ludovic Court=C3=A8s writes: > >> Morning! >> >> Cl=C3=A9ment Lassieur skribis: >> >>> Because it may take time and thus prevent PROCESS-SPECS to run every IN= TERVAL >>> seconds. >>> >>> * src/cuirass/base.scm (process-specs): move the COMPILE invocation ins= ide >>> 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 = commit) >>> + (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= separate >> thread; the calling fiber then =E2=80=9Cwaits=E2=80=9D for a message fro= m that 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? > > Well, no :-) > > My understanding is that non-blocking is, actually... blocking, because > get-message is blocking. (It doesn't block the scheduler because it's > in another thread, but that's not the problem here.) > > What I wanted to fix here is the fact that if the build takes one hour, > we will block for one hour in the COMPILE call, and process-spec won't > return for one hour. If it doesn't return for one hour, that means we > can't evaluate anything else for all that time. Oh, I see. However we have to wait for compilation to complete before continuing anyway, no? > With my change, the one-hour call will be in the fiber, which means that > process-spec can return, and other evaluations can be processed. > > But this is untested (because compilation doesn't work IIRC), so I can't > be sure. Yeah, what about this plan: let=E2=80=99s forget about this patch, and let= =E2=80=99s remove support for compilation altogether in a future patch. WDYT? Ludo=E2=80=99.