From b82934a1c0a87a0c1da3a56879c5b7601eec0b24 Mon Sep 17 00:00:00 2001 From: carpenat Date: Sat, 14 May 2022 13:14:28 +0000 Subject: [PATCH] chore: comment the why of thread::spawn --- .../src/routes/extensions/simple_search/mod.rs | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/angelsharkd/src/routes/extensions/simple_search/mod.rs b/angelsharkd/src/routes/extensions/simple_search/mod.rs index 89d373a..f116568 100644 --- a/angelsharkd/src/routes/extensions/simple_search/mod.rs +++ b/angelsharkd/src/routes/extensions/simple_search/mod.rs @@ -61,8 +61,18 @@ async fn search( /// Immediately returns. Spawns an asynchronous task to complete the haystack /// refresh in the background. async fn refresh(haystack: Haystack) -> Result { + // Note: why use `thread::spawn()`? Previously I had used `tokio::spawn()` + // here. The difference is that `tokio::spawn()` spawns the task in a thread + // from Tokio's dedicated threadpool. This means that this thread is no + // longer available to answer requests from the HTTP server. This + // effectively meant that during a refresh, large blocking portions of code + // were preventing people from running searches, and they would receive 504 + // Gateway Timeouts from the reverse proxy. Using a plain `thread::spawn()`, + // we ensure that a thread outside of Tokio's or Rayon's threadpools. + // Therefore, searches can still happen during even the most intensive of + // refreshes. + // Run refresh as a background task and immediately return. - // TODO: notes on why this is the way it is thread::spawn(move || { if let Err(e) = haystack.refresh() { error!("{}", e.to_string());