search

dylanmc / cs393_vm_api

Virtual memory abstraction & methods for constructing, accessing, manipulating and destroying address spaces
4 stars 28 forks source link

`Arc` vs `&` in `AddressSpace` #7

Open rileyshahar opened 1 year ago

rileyshahar commented 1 year ago

The methods of AddressSpace take &dyn DataSource, e.g.: https://github.com/dylanmc/cs393_vm_api/blob/2d1299b1d4ee05cdcac73f3ef0ed3209fb9e85f1/src/address_space.rs#L43-L50

But the struct itself stores Arc<dyn DataSource>: https://github.com/dylanmc/cs393_vm_api/blob/2d1299b1d4ee05cdcac73f3ef0ed3209fb9e85f1/src/address_space.rs#L9

My instinct is that add_mapping should just take an Arc. The broader issue is that the methods of DataSource only have shared access to self, and there's no way to safely upcast &self to Arc<self>. So as I see it, either:

  1. The DataSource methods to have a stronger reference to self.
  2. MapType needs to store &dyn DataSource (maybe fine! The DataSource API is immutable anyway).
  3. There's some clever invariant that will make it ok to unsafely mutate &dyn DataSource into Arc<dyn DataSource>. This seems pretty unlikely to me.
dylanmc commented 1 year ago

Dyn trait objects in Rust are new to me - so these are great insights.