[Updated] D9684: copies-rust: move CPU-heavy Rust processing into a child thread

SimonSapin phabricator at mercurial-scm.org
Fri Jan 22 16:48:29 UTC 2021


SimonSapin added inline comments.

INLINE COMMENTS

> Alphare wrote in copy_tracing.rs:54
> This is a better comment, I almost said something on the last commit

This was a pre-existing comment, the previous commit only moved it around. But yeah I could have included this change in the previous commit.

> Alphare wrote in copy_tracing.rs:78
> This will not honor the `RAYON_NUM_THREADS` environment variable that we use to contain the number of threads in tests, but also technically for users as an implementation detail. Should we use `rayon` threads here so as to have the same threadpool everywhere?

I feel that starting a pool of multiple thread to run a single task on it and leaving it running until process exit is counter-productive compared to the one thread started and then stopped here. Unless `combine_changeset_copies_wrapper` itself is called with high concurrency from many Python threads (which would contend the GIL) we’re not gonna have many of these Rust threads.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D9684/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D9684

To: SimonSapin, #hg-reviewers
Cc: Alphare, mercurial-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-patches/attachments/20210122/14611fce/attachment-0002.html>


More information about the Mercurial-patches mailing list