Set default threads num instead of zero by drwtsn95 · Pull Request #1598 · projectdiscovery/naabu

drwtsn95 · 2025-12-03T09:06:31Z

A zero value for the number of threads is practically meaningless, because then the sizedwaitgroup will generate 2^32 - 1 goroutines for scans of large subnets, which will consume a huge amount of RAM.

It is important to note that the above situation occurs when using the example "Using naabu as a library" from README.md , because there is just a zero value set due to the fact that it is simply not specified.

Summary by CodeRabbit

Refactor
- Centralized the default worker thread count into a single exported constant for consistent defaults across the runner.
Behavior
- The runner now applies that centralized default automatically when no thread count is provided.
- The command-line flag default for thread count now reflects the centralized default value.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

coderabbitai · 2025-12-03T09:06:43Z

Walkthrough

Adds an exported constant DefaultThreadsNum = 25; replaces hardcoded 25 with that constant for the CLI -c flag default and assigns it during Runner construction when options.Threads == 0. No other behavioral or error-handling changes.

Changes

Cohort / File(s)	Summary
Constant addition `pkg/runner/default.go`	Added exported constant `DefaultThreadsNum` set to `25`.
CLI default `pkg/runner/options.go`	Replaced hardcoded `25` with `DefaultThreadsNum` as the default value for the `-c` flag.
Runner initialization `pkg/runner/runner.go`	If `options.Threads == 0`, set `options.Threads = DefaultThreadsNum` before constructing the Runner.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Focus review on:
- pkg/runner/options.go — ensure flag default/help text correctly references the constant.
- pkg/runner/runner.go — confirm default assignment doesn't override explicit user values and occurs at the intended initialization point.

Poem

A rabbit found a tidy spot, 🐇
A number named and placed on top,
Twenty-five hops in neat array,
Quiet defaults, no disarray,
Code hopped on—content to stop. ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main objective: setting a default thread number to prevent zero values. It aligns with all three modified files and directly addresses the core issue.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9ddd3a9 and 5bb7256.

📒 Files selected for processing (1)

pkg/runner/default.go (1 hunks)

🔇 Additional comments (1)

pkg/runner/default.go (1)

19-21: DefaultThreadsNum constant fits existing defaults pattern

Exporting DefaultThreadsNum = 25 with a short explanatory comment is consistent with the other default constants in this package and makes the threads default reusable from a single place. Looks good.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

A zero value for the number of threads is practically meaningless, because then the sizedwaitgroup will generate 2^32 - 1 goroutines for scans of large subnets, which will consume a huge amount of RAM.

coderabbitai

Actionable comments posted: 0

🧹 Nitpick comments (1)

pkg/runner/default.go (1)

18-19: DefaultThreadsNum constant fits existing defaults; consider brief rationale comment

Adding DefaultThreadsNum = 25 to the shared defaults block is consistent and gives a single source of truth for the default thread count. Behaviorally this is a safe, targeted fix for the zero-threads issue.

Optionally, you might add a short comment explaining why 25 was chosen (e.g., balance between parallelism and memory usage), to help future tuning.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a4481bd and 9ddd3a9.

📒 Files selected for processing (3)

pkg/runner/default.go (1 hunks)
pkg/runner/options.go (1 hunks)
pkg/runner/runner.go (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

pkg/runner/options.go
pkg/runner/runner.go

Mzack9999 · 2025-12-04T08:41:01Z

@coderabbitai create an issue for this PR related to better handling of default thread number

coderabbitai · 2025-12-04T08:41:41Z

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

@Mzack9999, I'll create an issue for better handling of the default thread number.

🏁 Script executed:

#!/bin/bash
# Create a GitHub issue for better handling of default thread number

gh issue create \
  --title "Improve default thread number handling" \
  --body "This issue is a follow-up to PR #1598 (https://github.com/projectdiscovery/naabu/pull/1598) which fixed a critical bug where a zero value for the number of threads led to the creation of 2^32-1 goroutines, causing very high RAM usage.

## Current State
PR #1598 introduced \`DefaultThreadsNum\` constant set to 25 and ensures it's applied when threads value is 0 or unspecified.

## Improvements Needed
Consider enhancing the default thread handling mechanism:
- Evaluate if the default value of 25 threads is optimal across different use cases
- Consider making the default adaptive based on system resources (CPU cores, available memory)
- Add validation to prevent edge cases that could lead to resource exhaustion
- Improve documentation for library users about thread configuration best practices

## Context
This issue particularly affects users utilizing naabu as a library, where thread count may be unspecified and defaults to zero.

Requested by: @Mzack9999
Related PR: #1598" \
  --assignee "Mzack9999"

Length of output: 53

@Mzack9999, I've created issue #1599 for better handling of the default thread number. The issue has been assigned to you and includes a reference back to this PR.

You can view it here: #1599

auto-assign bot requested a review from Mzack9999 December 3, 2025 09:06

Set default threads num instead of zero

9ddd3a9

A zero value for the number of threads is practically meaningless, because then the sizedwaitgroup will generate 2^32 - 1 goroutines for scans of large subnets, which will consume a huge amount of RAM.

drwtsn95 changed the title ~~Set default thread num instead of zero~~ Set default threads num instead of zero Dec 3, 2025

drwtsn95 force-pushed the default-threads-num branch from a4481bd to 9ddd3a9 Compare December 3, 2025 09:09

coderabbitai bot reviewed Dec 3, 2025

View reviewed changes

adding comment

5bb7256

coderabbitai bot mentioned this pull request Dec 4, 2025

Improve default thread number handling #1599

Closed

Mzack9999 linked an issue Dec 4, 2025 that may be closed by this pull request

Improve default thread number handling #1599

Closed

Mzack9999 merged commit 0a01d14 into projectdiscovery:dev Dec 4, 2025
10 checks passed

BrewTestBot mentioned this pull request Jan 21, 2026

naabu 2.4.0 Homebrew/homebrew-core#263849

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Set default threads num instead of zero#1598

Set default threads num instead of zero#1598
Mzack9999 merged 2 commits intoprojectdiscovery:devfrom
drwtsn95:default-threads-num

drwtsn95 commented Dec 3, 2025 •

edited by coderabbitai bot

Loading

Uh oh!

coderabbitai bot commented Dec 3, 2025 •

edited

Loading

Uh oh!

coderabbitai bot left a comment

Uh oh!

Mzack9999 commented Dec 4, 2025

Uh oh!

coderabbitai bot commented Dec 4, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

drwtsn95 commented Dec 3, 2025 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Uh oh!

coderabbitai bot commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Estimated code review effort

Poem

Pre-merge checks and finishing touches

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Mzack9999 commented Dec 4, 2025

Uh oh!

coderabbitai bot commented Dec 4, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

drwtsn95 commented Dec 3, 2025 •

edited by coderabbitai bot

Loading

coderabbitai bot commented Dec 3, 2025 •

edited

Loading