Hi folks! @nikomatsakis and I are planning to do a pass over the shared-state laid out in the PR audit. We plan to take a breadth-first approach, attempting to put each piece of shared state into a bucket:
In each case there are subcategories (e.g., in several places fine-grained locks around individual fields were introduced, with unclear atomicity ramifications; in many cases these could be consolidated into a single, more coarse-grained lock).
The goal of the meeting is to categorize as much of the state as we can, and hopefully get to a point where we can write up more detailed issues for what we want to do in most cases. Afterward, we can figure out how to divide up the next steps.
The meeting will be held on Zoom and recorded. The event link is here.
cc @simulacrum @Santiago Pastorino
Would you be interested / feel it beneficial for others to attend as well? I can make that slot.
@Aaron Turon ^
Ah, yes, sorry that wasn't clear! This was meant as a general invite for anybody who'd like to join, especially if you think you might like to work on the issues that will come out of it
Okay sounds good, I'll most likely be there then. Thanks for the invite!
On my way :)
ps @Santiago Pastorino this meeting might interest you too, if you're avail :point_up: (happening now)
@Aaron Turon I'd personally be willing to take on work like e.g. the refactor to librustc_error::Handler and such; do we want some sort of document for this? Maybe just opening a bunch of issues on rust-lang/rust and assigning folks is a good idea
Re: Mir Stealing, not sure if this makes sense, but would something like Event Sourcing be a viable alternative to stealing? I think this would really only be useful if the intermediate states of MIR transformation needed to be accessed after some optimizations had already been performed. Would be helpful in keeping space small-ish, but would take some (not sure if this would be small or large in the rustc scale) perf hits to recompute intermediate/final states
@simulacrum yeah i think we're ready to open issues for tracking. i do want to think a bit about the audit/doc strategy as well, but we can develop that organically
@Paul Faria what do you mean by "event sourcing"?
@Aaron Turon sounds good -- do you want to open issues? should we hold off on any work until we can have another meeting to maybe get a broader sense of goals and such?
It's a pattern used in some backend web system for tracking lots of state changes over time. https://martinfowler.com/eaaDev/EventSourcing.html is a good reference from that perspective. Another way to think about it might be commits in a repo. You have a base state, which might be the original MIR, and you store the "patches" to the MIR. Then when you need the MIR at a specific point, you apply the patches in order. This becomes more complicated if you have to account for conflicts
@simulacrum I'm happy to open issues, and set up a tracking issue for the overview. my gut feeling is that we shouldn't block on another meeting, but rather get a topic here going on how we want to approach audit/documentation. i think it's best for us to dive in, see how things are feeling, and coordinate as we go on developing the approach. how does that sound to you?
It might be overkill though for rustc's needs though.
@simulacrum that sounds awesome! just drop a note in the shared doc for the time being, and when i open the issue i'll go ahead and assign you :heart:
should be live now
ty::Steal cannot deadlock btw. The
steal operation is bounded and
borrow can only block on it.
@Zoxc ah, I guess it's a read/write lock, duh.
in that case, I agree