Hi! [email protected] (宋文武) skribis:
> Hi, sorry for my late response. No problem, it was worth waiting. ;-) > [email protected] (Ludovic Courtès) writes: [...] >> (Also, longer-term, we’d want to do that other way around, which is to >> update the report every N milliseconds, as opposed to just printing >> something when a chunk has been transferred.) >> > > Yes, so the elapsed time won't be freezed, and here is my try using > thread: [...] > From 4036ce5de7bf3b98327010bbfbf75029f3d0b572 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <[email protected]> > Date: Fri, 8 Sep 2017 22:49:03 +0800 > Subject: [PATCH] download: Report the progress asynchronously in another > thread. > > * guix/utils.scm (<progress-reporter>): New record type. > (call-with-progress-reporter): New procedure. > * guix/build/download.scm (dump-port*, progress-reporter/file): New > procedures. > (ftp-fetch, http-fetch): Use them. > (progress-proc): Remove procedure. > * guix/scripts/substitute.scm (progress-report-port): Rewrite in terms of > <progress-reporter>. > (process-substitution): Adjust accordingly. Impressive! I have a couple of concerns though: 1. Using a thread “just” for progress reporting seems quite heavyweight, though maybe that’s OK. 2. As per POSIX, we cannot mix ‘fork’ and threads, so programs that use ‘primitive-fork’ should not also use threads. One such program is (guix scripts substitute), via ‘decompressed-port’. Guile rightfully emits a warning when a multithreaded program calls ‘primitive-fork’: https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/posix.c#n1224 3. “Atomic boxes” are a Guile 2.2 feature, but we still support 2.0. To address these, I would use ‘abort-to-prompt’ & co., possibly with “suspendable ports”, but this is a 2.2 feature. (It may be that we should use Fibers directly.) Tricky! Not sure what to do here. Thoughts? Ludo’.
