On Tue, Apr 11, 2023 at 10:05:58AM +0200, Eelco Chaudron wrote:
>
>
> On 7 Apr 2023, at 4:06, Songtao Zhan wrote:
>
> > To: d...@openvswitch.org,
> > i.maxim...@ovn.org
> >
> > 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 <zhan...@chinatelecom.cn>
> > ---
> > 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>.
if we cannot identify which thread is writting the log, we cannot fix
the issuse by log. Maybe it would be make sense to user the last upper
characters
> Acked-by: Eelco Chaudron <echau...@redhat.com>
>
> > + }
> > pthread_setname_np(pthread_self(), pname);
> > #elif HAVE_NETBSD_PTHREAD_SETNAME_NP
> > pthread_setname_np(pthread_self(), "%s", pname);
> > --
> > 2.39.1
> >
> >
> >
> >
> > zhan...@chinatelecom.cn
> > _______________________________________________
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
