Steve/link2 #108
Steve/link2 #108
Conversation
| /// - `utc_time`: The stored monotonic Utc time. | ||
| /// - `week`: The stored week value from GPS Time messages. | ||
| pub struct BaselineTab<'a, S: CapnProtoSender> { | ||
| pub struct BaselineTab<S: CapnProtoSender> { |
There was a problem hiding this comment.
Removed the existing lifetimes on tabs, because the references they were using were 'static so they were unneeded
| func: Box<dyn FnMut(SBP, MaybeGpsTime) + Send + 'a>, | ||
| msg_types: &'static [u16], | ||
| enum Callback<'a> { | ||
| Id { |
There was a problem hiding this comment.
Needed id based callbacks for settings stuff, it was easier to just include it there than breaking it out
| pub solution_velocity: Mutex<SolutionVelocityTab<S>>, | ||
| pub advanced_spectrum_analyzer: Mutex<AdvancedSpectrumAnalyzerTab<S>>, | ||
| pub status_bar: Mutex<StatusBar<S>>, | ||
| _link: broadcaster::Link<'link>, |
There was a problem hiding this comment.
Added this just to show that everything compiles when Tabs is holding a Link (so should work for Fileio as well)
| pub fn link<'scope>(&self) -> Link<'scope> | ||
| where | ||
| 'env: 'scope, | ||
| { | ||
| let link: Link<'scope> = unsafe { std::mem::transmute(self.link.clone()) }; | ||
| link | ||
| } |
There was a problem hiding this comment.
This lets you create Links from LinkSource with distinct lifetimes ('scope), that are at most as long as 'env (the 'parent' lifetime). This basically forces the behavior that @silverjam was talking about w.r.t. how clone should intuitively behave in this case.
There was a problem hiding this comment.
This makes sense to me!
notoriaga
requested review from
john-michaelburke and
silverjam
and removed request for
john-michaelburke
| use std::{convert::TryInto, marker::PhantomData, sync::Arc, time::Duration}; | ||
|
|
||
| use crossbeam::channel; | ||
| use parking_lot::Mutex; |
There was a problem hiding this comment.
What do we gain with the parkinglot mutex? Looks like it doesnt require unwrapping the lock.
There was a problem hiding this comment.
It seems there are quite a few differences: https://amanieu.github.io/parking_lot/parking_lot/struct.Mutex.html#differences-from-the-standard-library-mutex
There was a problem hiding this comment.
Not sure what specifically we needed for this change though
There was a problem hiding this comment.
Oh yeah another thing I needed for the settings tab. It has a function to unlock a mutex without a guard (https://docs.rs/lock_api/0.4.5/lock_api/struct.Mutex.html#method.force_unlock) which I needed for the FFI stuff. Don't actually need it here I guess.
They are supposed to be faster, and they don't allocate their contents on the heap like std mutexs. You don't have to unwrap them because they don't 'poison'. So if a thread holding a mutex panics it just releases the mutex. Which is supposed to be fine for 'normal' panics like unwrap() and stuff. The poisoning is an extra safeguard against panics that leave the contents of the mutex in an 'undefined' state which is apparently very uncommon
There was a problem hiding this comment.
Sounds like it should be safe for us then too
notoriaga
force-pushed
the
steve/link2
branch
from
fdbb4cb to
57df8ed
Compare
This reverts commit f1f8385.
No description provided.