Re: [WIP][PATCH] download: Don't report the progress too fast

[Ludovic Courtès]

Hi!

address@hidden (宋文武) skribis:

> Hi, sorry for my late response.

No problem, it was worth waiting.  ;-)

> address@hidden (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?= <address@hidden>
> 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’.