Skip to content

utils: report failure to set a thread name, and fall back to short names - #203

Open
lhoward wants to merge 1 commit into
L-Acoustics:devfrom
PADL:lhoward/thread-names
Open

lhoward wants to merge 1 commit into
L-Acoustics:devfrom
PADL:lhoward/thread-names

Conversation

@lhoward

@lhoward lhoward commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

On Linux, pthread_setname_np fails with ERANGE for a name longer than 15 characters, and setCurrentThreadName ignores the result and returns true. Every name the library sets is longer than that (avdecc::watchDog is 16 characters, avdecc::PCapInterface::Capture 30), so none of them take effect: each thread keeps the name it inherited from the thread that created it, which makes the library's threads hard to tell apart in top, perf or a debugger.

  • Return value: setCurrentThreadName now returns whether the name was set, from the result of pthread_setname_np (Linux and macOS) or prctl, and no longer truncates.
  • Callers: each call site that can run on Linux falls back to a short name when the full one is rejected: avdecc:watchDog, avdecc:SM, avdecc:ctrlSM, avdecc:pcap, avdecc:serial, avdecc:local and avdecc:virtual. An executor falls back to Exec: followed by the first 10 characters of the last :: component of its name, which tells executors apart.

This overlaps #204 in src/watchDog.cpp and CHANGELOG-avdecc.md, so whichever is merged second needs a small rebase.

Testing: builds on dev, and together with the watchdog and state machine changes in #204 and #205, the unit tests give the same results as dev without them: 289 of 292 pass. INTEGRATION_EndStation.DestroyWhileMessageInflight_pcap and INTEGRATION_ProtocolInterfacePCap_F.VuDelegate fail either way, as they need pcap access to a real interface.

🤖 Generated with Claude Code

https://claude.ai/code/session_012i5Dd3gCyYqp4X7vxhSmxh

@lhoward
lhoward marked this pull request as ready for review September 14, 2026 05:18
@christophe-calmejane

Copy link
Copy Markdown
Collaborator

I'm wondering if it wouldn't be better for the function to return the error status, and let the caller truncate itself (it probably better know how to properly reduce the length of the string instead of cutting the end, which could prevent easy identification of the thread).
Anyhow, thanks for the report/PR, I wasn't aware of this issue.

Linux allows a thread name of at most 15 characters, and
pthread_setname_np fails with ERANGE for a longer one, but
setCurrentThreadName ignored the result and returned true. Every name
the library sets is longer than that ("avdecc::watchDog" is 16
characters, "avdecc::PCapInterface::Capture" 30), so none took effect:
each thread kept the name it inherited from the thread that created it.

setCurrentThreadName now returns whether the name was set, on macOS and
Linux too, rather than truncating it, and each caller that can run on
Linux falls back to a name short enough for it that still identifies
its thread.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012i5Dd3gCyYqp4X7vxhSmxh
@lhoward
lhoward force-pushed the lhoward/thread-names branch from 3a2636f to 29db58b Compare September 14, 2026 20:46
@lhoward lhoward changed the title utils: truncate thread names to the Linux limit utils: report failure to set a thread name, and fall back to short names Sep 14, 2026
@lhoward

lhoward commented Sep 14, 2026

Copy link
Copy Markdown
Contributor Author

Thanks Christophe, good point. I've reworked it that way: setCurrentThreadName no longer truncates, and returns whether the name was set, from pthread_setname_np's result on Linux and macOS. When the full name is rejected, each call site that can run on Linux falls back to a short name that still identifies the thread: avdecc:watchDog, avdecc:SM, avdecc:ctrlSM, avdecc:pcap, avdecc:serial, avdecc:local, avdecc:virtual, and for executors Exec: plus the last component of the executor's name. It's rebased onto dev too.

@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants