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

[宋文武]

address@hidden (Ludovic Courtès) writes:

> [...]
>> 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.

Yes..
>
>   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

Oh, thanks for pointing it out!
>
>    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.)

Sure, I’d like to try fibers.  When we can drop the support of Guile
2.0?  (I guess one sign is that 2.2 is in the debian stable.)

>
> Tricky!  Not sure what to do here.
>
> Thoughts?

How about replace the use of thread from ‘progress-reporter/file’ by a
‘rate-limited’ render procedure, and then change the elapsed time to
ETA, which is okay without updating in seconds?