Hey @Aaron Turon, @Zoxc, @lwshang and others with an interest in @WG-parallel-rustc :
Should we find a time to discuss status and plans?
Do we need a sync discussion? I think just merging my PRs and resume existing plans should suffice
"Do we need a sync discussion?" -- that's too meta
if there is a meeting, I'm interested
note: i jotted down some thoughts in the "refcell-vs-lock" thread
Yeah. My update and thoughts:
In the design meeting, we talked about a pre-req being that we address some of the documentation concerns. I had hoped to head that up but of course had no time. But I asked @Aaron Turon to look into it, and gave him an overview of the design plus tips to the various bits of public comments. I'd still like to see more progress on the "design docs" before we go forward -- I think that's important.
(I'll go look at the refcell-vs-lock topic in more detail.)
I'm not sure yet what I think about those concerns. =) I think at minimum I'd like to see a kind of "audit and refactoring list" and a plan for moving forward, but I'm not sure if we need to block on that work being 100% done. The concern of course is that there are very "low probability" bugs that start to appear only once we've released parallel compilation to the public.
I guess at minimum this suggests that we should be sure to do a long enough "opt-in" cycle.
yeah, same -- i think as long as we are steadily working through these concerns and tracking where concurrency issues might arise, we can make improvements in parallel (hah) with the community starting to benefit
re: writing up docs etc, i'd love to go to town on that in the near future -- most likely next week since i'll be traveling to give a conference talk next week
i can start tidying up my review notes this week though, for sure
sounds good to me
hey y'all! i've updated the main tracking issue, and in particular it now links to a sub-tracking issue for the initial shared-state audit. Once the initial audit is complete, I'll work to produce a set of fine-grained issues for areas of shared state to assess, leading to either (1) durable documentation including invariants, atomicity, and lock order, or (2) refactoring to remove the state
those fine-grained issues should be great for splitting up amongst the group if people want to tackle stuff in parallel
once i've got those issues created, i plan to focus on reviewing outstanding PRs for a while