[PR #2023] [MERGED] fix: Prevent task reaping from blocking #2760

New issue

Closed

opened 2026-03-16 11:06:49 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 11:06:49 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hickory-dns/hickory-dns/pull/2023
Author: @lpraneis
Created: 9/13/2023
Status: ✅ Merged
Merged: 9/15/2023
Merged by: @djc

Base: main ← Head: now-or-never-flattening

📝 Commits (1)

85311a5 fix: Prevent task reaping from blocking

📊 Changes

2 files changed (+32 additions, -2 deletions)

View changed files

📝 crates/resolver/src/name_server/connection_provider.rs (+4 -1)
📝 crates/server/src/server/server_future.rs (+28 -1)

📄 Description

Previously, the reap_tasks function could cause a tokio task to spinloop.

This is because FutureExt::now_or_never returns an Option where T is the inner future's resolution type. If join_set.join_next() returned None, indicating there are no longer tasks to join, the FutureExt::now_or_never would return Some(None).

Then, the is_some() spinloop in this function would see the Some(None) and busy loop calling FutureExt::now_or_never.

The fix here is to use Option::flatten to transform the nested Option. Now, the call to reap_tasks will only loop when the inner join_set.join_next returns Some(..), indicating that a task is already complete. When there are no tasks complete, or when the JoinSet is empty and returns None, the reap_tasks function will immediately yield.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hickory-dns/hickory-dns/pull/2023 **Author:** [@lpraneis](https://github.com/lpraneis) **Created:** 9/13/2023 **Status:** ✅ Merged **Merged:** 9/15/2023 **Merged by:** [@djc](https://github.com/djc) **Base:** `main` ← **Head:** `now-or-never-flattening` --- ### 📝 Commits (1) - [`85311a5`](https://github.com/hickory-dns/hickory-dns/commit/85311a5ee428e02eac6c3e6e6f4ed8300216fa4e) fix: Prevent task reaping from blocking ### 📊 Changes **2 files changed** (+32 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `crates/resolver/src/name_server/connection_provider.rs` (+4 -1) 📝 `crates/server/src/server/server_future.rs` (+28 -1) </details> ### 📄 Description Previously, the `reap_tasks` function could cause a tokio task to spinloop. This is because `FutureExt::now_or_never` returns an Option<T> where T is the inner future's resolution type. If `join_set.join_next()` returned None, indicating there are no longer tasks to join, the `FutureExt::now_or_never` would return `Some(None)`. Then, the `is_some()` spinloop in this function would see the `Some(None)` and busy loop calling `FutureExt::now_or_never`. The fix here is to use `Option::flatten` to transform the nested Option. Now, the call to `reap_tasks` will only loop when the inner `join_set.join_next` returns `Some(..)`, indicating that a task is already complete. When there are no tasks complete, or when the `JoinSet` is empty and returns `None`, the `reap_tasks` function will immediately yield. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>