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

Introduce FlexScope #4

Closed
wants to merge 8 commits into from
Closed

Conversation

Zoxc
Copy link

@Zoxc Zoxc commented Jan 6, 2020

This serves the same function as #1, but with a cleaner API.

My plan is to put a FlexScope along with rustc's arenas so we can spawn background tasks which contains references to the arena.

cc @cuviper @nikomatsakis

@Zoxc
Copy link
Author

Zoxc commented Jan 14, 2020

One interesting thing you can do with this is to have a Arc<FlexScope<'static>> and no lifetimes would be required.

@nikomatsakis
Copy link

@Zoxc can you include a description of what the API is and how it is meant to be used? Some examples might also help.

@nikomatsakis
Copy link

To be clear:

I realize I could read rust-lang/rust#67965, as well as the source of this PR, and get some sense of what is going on, but I would really prefer to have a write-up of the design in my head before I start reviewing, so that I'm not trying to reverse engineer what is going on.

From a pure quality POV, I think this PR also needs some tests.

But my biggest concern remains that there seems to be a disconnect of "overall vision" on what we are doing. From how I understood things, we were primarily in a phase of "cleaning up and documenting" the parallel support, and we were especially looking at either moving to a completely distinct parallel runtime for rustc (presumably a quite simple one) or else moving to "base rayon". But this PR seems to be doing neither of those things.

That said, I can definitely believe that this is a useful construct. I sort of infer that it is essentially a scope where, instead of getting a &Scope, you get a FlexScope that is not borrowed? (I think you mentioned something like that to me in privmsg on Zulip, now, I forget.)

But this definitely feels like a major design piece that should be discussed. Particularly when we had been talking on and off about trying to reduce the places in rustc that we are introducing parallelism, i.e., to restrict things to relatively high-level dispatch in an effort to simplify.

@nikomatsakis
Copy link

Anyway I guess I should move this to Zulip, this PR doesn't seem like the right place to talk about everybody getting on the same page since it's just us two here :)

@nikomatsakis
Copy link

Closing this pull request as Zoxc is stepping back from compiler development; see rust-lang/team#316.

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 this pull request may close these issues.

2 participants