Uh oh!
There was an error while loading. Please reload this page.
Mechanical translation towards making GlobalCtxt implement Sync - #46958
Mechanical translation towards making GlobalCtxt implement Sync#46958Zoxc wants to merge 1 commit into
Conversation
rust-highfive
commented
Dec 23, 2017
(rust_highfive has picked a reviewer for you, use r? to override) |
bors
commented
Dec 23, 2017
☔ The latest upstream changes (presumably #46842) made this pull request unmergeable. Please resolve the merge conflicts. |
alexcrichton
commented
Jan 4, 2018
ping @michaelwoerister, did you want to take a look at this? |
michaelwoerister
commented
Jan 5, 2018
Nominating for discussion in the @rust-lang/compiler team meeting. This is a huge change that I can't approve by myself. Also, I think we should have a broader, more open discussion about multi-threading support in the compiler. I feel that such a thing would need an RFC. |
eddyb
commented
Jan 5, 2018
I've insistented on numerous occasions on IRC that It is plausible that you get some speedup even with locks everywhere but it's not ideal IMO. |
nikomatsakis
commented
Jan 5, 2018
I do feel like parallelizing rustc seems like a good goal but I would like to see some more design discussion. That said, I don't know that I have an objection to this PR in particular, which seems like it's probably necessary groundwork? If I understand what's happening here, we're basically just redirecting names on the basis of a configuration option? (i.e., we're still going to be using That said, I think I might prefer to use names Thoughts? |
That is indeed what is happening.
There are a couple of problems with that.
|
nikomatsakis
commented
Jan 11, 2018
We discussed this in the @rust-lang/compiler meeting. Consensus was that @Zoxc would open a thread on internals and we would try to ensure we have some level of agreement on the overall plan before we go forward. Closing PR for now. |
This PR is split out from #45912.