Thread naming: enforce 15-char limit + simplify labels - #6212
Conversation
ximinez
left a comment
There was a problem hiding this comment.
These are all very minor, except one with the version number. Feel free to ignore the others.
bthomee
left a comment
There was a problem hiding this comment.
Looks good. Regarding consistency in naming, I see several variants in the original code that you mostly maintained here, while now is a good time to move towards better naming.
abcXyzAbc XyzAbc.xyz
so essentially inconsistent casing and inconsistent separation. I would suggest to just drop the space and the period, and use pascal case.
Done |
This change builds on the thread-renaming PR (#6212), by renaming the main thread name to reduce ambiguity in performance monitoring tools.
…#6212) This change continues the thread naming work from #5691 and #5758, which enables more useful lock contention profiling by ensuring threads/jobs have short, stable, human-readable names (rather than being truncated/failing due to OS limits). This changes diagnostic naming only (thread names and job/load-event labels), not behavior. Specific modifications are: * Shortens all thread/job names used with `beast::setCurrentThreadName`, so the effective Linux thread name stays within the 15-character limit. * Removes per-ledger sequence numbers from job/thread names to avoid long labels. This improves aggregation in lock contention profiling for short-lived job executions.
…#6212) This change continues the thread naming work from #5691 and #5758, which enables more useful lock contention profiling by ensuring threads/jobs have short, stable, human-readable names (rather than being truncated/failing due to OS limits). This changes diagnostic naming only (thread names and job/load-event labels), not behavior. Specific modifications are: * Shortens all thread/job names used with `beast::setCurrentThreadName`, so the effective Linux thread name stays within the 15-character limit. * Removes per-ledger sequence numbers from job/thread names to avoid long labels. This improves aggregation in lock contention profiling for short-lived job executions.
…#6212) This change continues the thread naming work from #5691 and #5758, which enables more useful lock contention profiling by ensuring threads/jobs have short, stable, human-readable names (rather than being truncated/failing due to OS limits). This changes diagnostic naming only (thread names and job/load-event labels), not behavior. Specific modifications are: * Shortens all thread/job names used with `beast::setCurrentThreadName`, so the effective Linux thread name stays within the 15-character limit. * Removes per-ledger sequence numbers from job/thread names to avoid long labels. This improves aggregation in lock contention profiling for short-lived job executions.
…XRPLF#6212) This change continues the thread naming work from XRPLF#5691 and XRPLF#5758, which enables more useful lock contention profiling by ensuring threads/jobs have short, stable, human-readable names (rather than being truncated/failing due to OS limits). This changes diagnostic naming only (thread names and job/load-event labels), not behavior. Specific modifications are: * Shortens all thread/job names used with `beast::setCurrentThreadName`, so the effective Linux thread name stays within the 15-character limit. * Removes per-ledger sequence numbers from job/thread names to avoid long labels. This improves aggregation in lock contention profiling for short-lived job executions.
This change builds on the thread-renaming PR (XRPLF#6212), by renaming the main thread name to reduce ambiguity in performance monitoring tools.
High Level Overview of Change
This PR continues the thread naming work from #5691 and #5758.
Changes:
Context of Change
Enable more useful lock contention profiling by ensuring threads/jobs have short, stable, human-readable names (rather than being truncated/failing due to OS limits).
Note: This changes diagnostic naming only (thread names and job/load-event labels), not behavior.
Type of Change
.gitignore, formatting, dropping support for older tooling)API Impact
libxrplchange (any change that may affectlibxrplor dependents oflibxrpl)