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

Work towards thread safety in rustc #46779

Merged
merged 8 commits into from
Dec 22, 2017
Merged

Conversation

Zoxc
Copy link
Contributor

@Zoxc Zoxc commented Dec 17, 2017

This PR is split out from #45912. It contains changes which do not require the sync module.

@rust-highfive
Copy link
Collaborator

r? @estebank

(rust_highfive has picked a reviewer for you, use r? to override)

@Zoxc Zoxc assigned arielb1 and unassigned estebank Dec 17, 2017
@Zoxc Zoxc force-pushed the par-merge-without-sync branch from c67d30e to 6b295aa Compare December 17, 2017 01:58
@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 17, 2017
Ok(vec.into())
})
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing trailing newline

@@ -163,10 +163,6 @@ impl SpanData {
}
}

// The interner in thread-local, so `Span` shouldn't move between threads.
impl !Send for Span {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please make the interner thread-safe?

@@ -83,10 +83,6 @@ impl Decodable for Ident {
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct Symbol(u32);

// The interner in thread-local, so `Symbol` shouldn't move between threads.
impl !Send for Symbol { }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

@Zoxc
Copy link
Contributor Author

Zoxc commented Dec 17, 2017

@bjorn3 Thread-safety for the interners happens in a later commit.

@bjorn3
Copy link
Member

bjorn3 commented Dec 17, 2017

@Zoxc that commit doesnt seem to be included in this pr.

@Zoxc
Copy link
Contributor Author

Zoxc commented Dec 17, 2017

It is in #45912.

@michaelwoerister
Copy link
Member

Each PR must leave the compiler in safe/valid state. Implementing Send/Sync for Symbol without making the interners threadsafe is not an option.

@Zoxc
Copy link
Contributor Author

Zoxc commented Dec 18, 2017

@michaelwoerister The !Send impls are not there for thread safety, but as a way to help ensure that Symbol types are only used with the interner they are created from. This trick no longer works when multiple threads share an interner. It also doesn't work if there are multiple interners per thread (which some of my upcoming patches allow).

@michaelwoerister
Copy link
Member

My concern is just that this PR, as it is, would leave the compiler in a state where I can send Symbols between threads and thus get wrong results from the auto-generated Eq implementation. The !Send implementation should only be removed if the same PR makes sure that that cannot lead to logic errors.

@@ -42,6 +42,8 @@ use std::cell::{RefCell, Cell};
use std::mem;
use std::rc::Rc;
use std::{error, fmt};
use std::sync::atomic::AtomicUsize;
Copy link
Contributor

@arielb1 arielb1 Dec 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

err_count probably needs to be done in a smarter way than here to assure thread-safety, so could you add a FIXME? In any case this is better than the way before this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In which case is this not thread safe?

let files = self.codemap.files();

if files.len() > 0 {
if self.codemap.files().len() > 0 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we need a better locking discipline for the codemap? It feels like "too many locks, not enough discipline". Maybe just add a fixme to it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that I just convert all RefCells into locks, there's probably plenty of places where there are too many locks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

@@ -163,10 +163,6 @@ impl SpanData {
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this sound?

@@ -384,8 +384,6 @@ impl<'a> ::std::cmp::PartialEq<InternedString> for &'a String {
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this sound?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, InternedString storing a &'static str isn't sound at all. I'll have to change it to using a u32 like Symbol.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well that made it unable to implement Deref<Target=str>, so I went with the approach suggested in a FIXME and just leak interned strings.

@Zoxc Zoxc force-pushed the par-merge-without-sync branch from 6b295aa to dbee5b9 Compare December 19, 2017 01:00
@Zoxc Zoxc force-pushed the par-merge-without-sync branch from dbee5b9 to 84ce4f1 Compare December 21, 2017 18:22
@Zoxc
Copy link
Contributor Author

Zoxc commented Dec 21, 2017

@bors r=arielb1

@bors
Copy link
Contributor

bors commented Dec 21, 2017

📌 Commit 84ce4f1 has been approved by arielb1

@bors
Copy link
Contributor

bors commented Dec 22, 2017

⌛ Testing commit 84ce4f1 with merge 2c037d5...

bors added a commit that referenced this pull request Dec 22, 2017
Work towards thread safety in rustc

This PR is split out from #45912. It contains changes which do not require the `sync` module.
@bors
Copy link
Contributor

bors commented Dec 22, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing 2c037d5 to master...

@bors bors merged commit 84ce4f1 into rust-lang:master Dec 22, 2017
slot.set(r + 1);
r
});
let id = NEXT_ATTR_ID.fetch_add(1, Ordering::SeqCst);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rust-lang/compiler Not sure how I feel about this kind of stuff - it will behave non-deterministically in any process running multiple rustc threads in parallel (atm rustc "owns" a thread).
IMO all thread-locals should change to scoped thread locals initialized to point to some memory owned by the thread that started the compilation, if we want multiple threads per rustc "instance".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I'll make this either a scoped thread local or put it in ParseSess if that happens to be easy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants