From 3064869d528f7969e3a53c6cbc1b79bdb4c4044f Mon Sep 17 00:00:00 2001 From: carpenat Date: Sat, 14 May 2022 13:20:26 +0000 Subject: [PATCH] chore: comments in haystack --- .../src/routes/extensions/simple_search/types.rs | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/angelsharkd/src/routes/extensions/simple_search/types.rs b/angelsharkd/src/routes/extensions/simple_search/types.rs index fa507cd..0cc5336 100644 --- a/angelsharkd/src/routes/extensions/simple_search/types.rs +++ b/angelsharkd/src/routes/extensions/simple_search/types.rs @@ -27,6 +27,16 @@ pub type Needles = Vec; type HaystackEntries = Vec>; /// Represents a searchable, refreshable collection of ACM extension data. +/// +/// Note: why use a Arc->Mutex->Pin->Box? The `Arc>` is required because +/// this haystack is borrowed across threads. I want all haystack refreshing to +/// take place on a separate thread so that searches can still be executed while +/// a background refresh takes place. +/// +/// The `Pin>` is used to ensure that the big block of new entries +/// generated during a refresh is pinned to one allocated portion of the heap. +/// This should prevent expensive moves or stack popping for that large chunk of +/// data which goes unchanged until it is dropped at the next refresh. #[derive(Clone)] pub struct Haystack { entries: Arc>>>, @@ -66,8 +76,9 @@ impl Haystack { /// Refreshes the haystack data by running relevant commands on a runner, /// parsing the results, and updating the entries field with the fresh data. - /// TODO: Do we want simultaneous refreshes to be possible? - /// TODO: The entry generation could probably be simplified and the number of clones reduced. + /// Note: multiple simultaenous refresh calls could starve the Rayon thread + /// pool used by `libangelshark`. The entry generation could probably be + /// simplified and the number of clones reduced. pub fn refresh(&self) -> Result<(), Error> { let mut runner = self.runner.to_owned();