On 7 Apr 2023, at 4:06, Songtao Zhan wrote:
> To: [email protected], > [email protected] > > The name of the current thread consists of a name with a maximum > length of 16 bytes and a thread ID. The final name may be longer > than 16 bytes. If the name is longer than 16 bytes, the thread > name will fail to be set > > Signed-off-by: Songtao Zhan <[email protected]> > --- > lib/util.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/lib/util.c b/lib/util.c > index 96a71550d..f145d5983 100644 > --- a/lib/util.c > +++ b/lib/util.c > @@ -645,6 +645,12 @@ set_subprogram_name(const char *subprogram_name) > free(subprogram_name_set(pname)); > > #if HAVE_GLIBC_PTHREAD_SETNAME_NP > + /* The maximum thead name including '\0' supported is 16. > + * add '>' at 14th position to highlight that the name was truncated. */ > + if (strlen(pname) > 15) { > + pname[15] = '\0'; > + pname[14] = '>'; Picking up the old conversation just to make sure we are all ok with this: >>>> >>>> Not sure what is better, but would it make sense to use the last upper >>>> characters? This way if we do truncate we know the internal thread id, as >>>> naming in OVS, in general, is “xasprintf("%s%u", aux.name, id)”. >>>> If we do this we could add some indication is was truncated, like >>>> “LONGTHREAD123456” would become “>NGTHREAD123456”. >>> >>> Thanks for your review, Assume that there are two threads, >>> disableXXthreadidAA and enableXXthreadidBB. If we keep the last >>> character, like XXthreadAA and XXthreadBB, we cannot get the thread >>> fuction by thread name. The thread id is not that important because we >>> can know it by 'ps' >> >> Yeah, truncating from the end seems more reasonable to me >> as we will likely truncate less meaningful parts. However, >> it might make sense to add something like '>' as at 14th >> position to highlight that the name was truncated. This >> will eat yet another symbol, but it will be harder to >> mistake one thread for another. >> >> What do you think? I’m fine with either way, as we should make sure that when we do add new threads this overflow does not likely happen. However just to clarify it’s not the thread ID that gets added to the end, but the internal thread number. So for example, if we truncate from the end, we can no longer identify which revalidator thread is causing a problem from the log. As they normally get created in order, all threads might get the same name, i.e. revalidator1235>. Acked-by: Eelco Chaudron <[email protected]> > + } > pthread_setname_np(pthread_self(), pname); > #elif HAVE_NETBSD_PTHREAD_SETNAME_NP > pthread_setname_np(pthread_self(), "%s", pname); > -- > 2.39.1 > > > > > [email protected] > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
