… that runs in parallel with the parent thread fetching data.
This can be disabled through a new config. CLI example:
hg --config=devel.copy-tracing.multi-thread=no
For now both threads use the GIL, later commits will reduce this.
Details
Details
Diff Detail
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
| rust/hg-cpython/src/copy_tracing.rs | ||
|---|---|---|
| 54 | This is a better comment, I almost said something on the last commit | |
| 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? | |
| rust/hg-cpython/src/copy_tracing.rs | ||
|---|---|---|
| 54 | 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. | |
| 78 | 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. | |