Skip to content

netutils/rexecd: add -t option to serve connections without a thread#3569

Open
JianyuWang0623 wants to merge 1 commit into
apache:masterfrom
JianyuWang0623:rexecd-threadless
Open

netutils/rexecd: add -t option to serve connections without a thread#3569
JianyuWang0623 wants to merge 1 commit into
apache:masterfrom
JianyuWang0623:rexecd-threadless

Conversation

@JianyuWang0623

Copy link
Copy Markdown
Contributor

Note: Please adhere to Contributing Guidelines.

Summary

Add a -t runtime option to rexecd to serve each accepted connection
inline in the main task, instead of spawning a detached worker thread
per connection.

By default rexecd calls pthread_create() for every connection, with a
CONFIG_NETUTILS_REXECD_STACKSIZE stack allocated from the heap, so that
sessions can run concurrently. With -t, the thread attributes are
skipped and doit() is called directly in the accept loop, avoiding the
per-connection worker stack. This helps on low-memory targets with
limited free heap. The trade-off is that connections are served one at a
time. Without -t, the existing behaviour is unchanged.

Impact

  • New opt-in -t flag; usage text updated.
  • Default behaviour and existing command lines are unaffected.
  • No new Kconfig options or dependencies; build process unchanged.
  • Backward compatible. Only trade-off with -t is loss of concurrency.

Testing

  • nuttx/tools/checkpatch.sh -f netutils/rexecd/rexecd.c => all checks pass.
  • Default mode: rexecd + rexec, thread-per-connection path works.
  • Threadless mode: rexecd -t + rexec, command runs inline, single
    session works end to end.

By default rexecd spawns a detached worker thread per accepted connection
to allow concurrent sessions. Add a "-t" runtime option to instead handle
each connection inline in the main task, avoiding the per-connection
worker stack (CONFIG_NETUTILS_REXECD_STACKSIZE) allocation from the heap.
This matters on low-memory targets with limited free heap.

With "-t", connections are served strictly one at a time: a long-running
or interactive command blocks the accept loop until it finishes. Without
it, the existing thread-per-connection behaviour is unchanged.

Assisted-by: GitHubCopilot:claude-4.8-opus
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants