• 0 Posts
  • 26 Comments
Joined 1 year ago
Cake day: June 12th, 2023
  • 2xsaiko@discuss.tchncs.detoProgrammer Humor@lemmy.ml•I love Rust
    5·
    3 days ago

    The bingo one actually uses crossbeam channels instead of mutexes, so that’s nice. I haven’t looked too closely at it though.

    I don’t think you can do too much about the Spectrum one if you want to keep the two threads, but here’s what I would change related to thread synchronization. Lemmy doesn’t seem to allow me to attach patch files for whatever reason so have an archive instead… https://dblsaiko.net/pub/tmp/patches.tar.bz2 (I wrote a few notes in the commit messages)

    Just to give the reason for Rc<RefCell> in the current project. I’m reading in a M3U file and I’m going to be referencing it against an Excel file. So in the structure for the m3u file, I have two BtreeMaps, one for order by channel number and one by name. Each containing references to the same Channel object.

    So basically it’s channels indexed by channel number and name? That one is actually one of the easy cases. Store indices instead:

    struct Channels {
  data: Vec<Channel>,
  by_number: BTreeMap<u32 /* or whatever */, usize>,
  by_name: BTreeMap<String, usize>,
}

// untested but I think it should compile
fn get_channel_by_name(ch: &Channels, name: &str) -> Option<&Channel> {
  Some(&self.data[*ch.by_name.get(name)?])
}