Mahmoud Al-Qudsi 455b744bca Port fd_monitor tests to rust ... This shows some of the ugliness of the rust borrow checker when it comes to safely implementing any sort of recursive access and the need to be overly explicit about which types are actually used across threads and which aren't. We're forced to use an `Arc` for `ItemMaker` (née `item_maker_t`) because there's no other way to make it clear that its lifetime will last longer than the FdMonitor's. But once we've created an `Arc<T>` we can't call `Arc::get_mut()` to get an `&mut T` once we've created even a single weak reference to the Arc (because that weak ref could be upgraded to a strong ref at any time). This means we need to finish configuring any non-atomic properties (such as `ItemMaker::always_exit`) before we initialize the callback (which needs an `Arc<ItemMaker>` to do its thing). Because rust doesn't like self-referential types and because of the fact that we now need to create both the `ItemMaker` and the `FdMonitorItem` separately before we set the callback (at which point it becomes impossible to get a mutable reference to the `ItemMaker`), `ItemMaker::item` is dropped from the struct and we instead have the "constructor" for `ItemMaker` take a reference to an `FdMonitor` instance and directly add itself to the monitor's set, meaning we don't need to move the item out of the `ItemMaker` in order to add it to the `FdMonitor` set later.		2023-03-05 00:33:53 -06:00
..
fd_monitor.rs	Port fd_monitor tests to rust	2023-03-05 00:33:53 -06:00
mod.rs	Port fd_monitor tests to rust	2023-03-05 00:33:53 -06:00