Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support borowing data in ignores WalkParallel #1410

Closed
epage opened this issue Oct 27, 2019 · 1 comment
Closed

Support borowing data in ignores WalkParallel #1410

epage opened this issue Oct 27, 2019 · 1 comment

Comments

@epage
Copy link
Contributor

epage commented Oct 27, 2019

I'd prefer to have my WalkParallel closures take references.

In general, this would improve the usability of WalkParallel because it takes a lot of work to change code from a trivial case to a non-trivial case (getting everything in Arc. etc). or from serial to parallel.

The way this is impacting me is that this will simplify my code because I can share a lot more code between my parallel (throwing everything in Arc) and non-parallel (directly using references).

@epage
Copy link
Contributor Author

epage commented Oct 27, 2019

I started implementing #469 to make it easier for me to work through the errors. I'm at the point of dealing with the threads. The way the threads are used, Rust can't know that the threads will all join by the end of the function call, requiring a 'static lifetime. Using crossbeam for scoped-threads should make this problem go away.

I wanted to check-in before going too much further. It looks like scope is in crossbeam-utils which is a dependency of crossbeam-channels, so this shouldn't add any new dependency to the full dependency tree.

epage added a commit to epage/ripgrep that referenced this issue Nov 28, 2019
This makes it so the caller can more easily refactor from
single-threaded to multi-threaded walking. If they want to support both,
this makes it easier to do so with a single initialization code-path.

Closes BurntSushi#1410
BurntSushi pushed a commit that referenced this issue Feb 17, 2020
This makes it so the caller can more easily refactor from
single-threaded to multi-threaded walking. If they want to support both,
this makes it easier to do so with a single initialization code-path. In
particular, it side-steps the need to put everything into an `Arc`.

This is not a breaking change because it strictly increases the number
of allowed inputs to `WalkParallel::run`.

Closes #1410, Closes #1432
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants
@epage and others