Plan for interior mutability in Thread / ThreadRef#2703
Plan for interior mutability in Thread / ThreadRef#2703sporksmith merged 4 commits intoshadow:mainfrom
Conversation
|
I think we could analogously remove the With the |
|
Oops, fixing clippy... |
I don't think we're going to have `&mut` methods on Thread. Therefore we don't need to get `&mut` references to threads. Therefore we don't need this wrapper.
0d957d8 to
322cec4
Compare
Codecov ReportBase: 68.09% // Head: 68.17% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #2703 +/- ##
==========================================
+ Coverage 68.09% 68.17% +0.08%
==========================================
Files 202 202
Lines 30414 30398 -16
Branches 5949 5948 -1
==========================================
+ Hits 20710 20724 +14
+ Misses 5000 4969 -31
- Partials 4704 4705 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
At a high level, I think we're going to need interior mutability in Thread/ThreadRef for similar reasons as in Process and Host - it'd be difficult to avoid incompatible borrows of Thread itself without it.
More concretely, I ran into a problem when changing SysCallCondition to store a tid instead of a
Thread*: someSysCallConditionmethods need to act on theThread. Since the condition itself is a member of theThread, it'll be impossible to simultaneously hold a&mut Threadand a reference to the condition. Using a&Threadinstead of a&mut Threadworks around this.I went a bit further here than strictly necessary and removed the
RootedRefCellwrapper aroundProcess'sThreadRefs altogether. I think as withProcesswe'll end up making ~all methods take&selfinstead of&mut self, so will never need to get a&mutreference to theThreadRef.We could leave the
RootedRefCellin place to make things easier in case we want to get&mutreferences later, but after working through the analagous problem inProcessI think I'm leaning towards following the yagni principle here. Better to make the code simpler now and only support as much functionality as we know we need.