09/12/2022 21:06, Tyler Retzlaff: > On Fri, Dec 09, 2022 at 08:48:14AM -0800, Stephen Hemminger wrote: > > On Fri, 09 Dec 2022 08:53:57 +0100 > > Thomas Monjalon <tho...@monjalon.net> wrote: > > > > > > > If some execution environment doesn't support thread names, it could > > > > > return a string that makes it possible for a human to identify the > > > > > thread, e.g. the tread id. Again, this is assuming that it is only > > > > > used for debugging, trace, and similar. > > > > > > > > i think this raises a good question. is the purpose of setting a thread > > > > name > > > > meant to be something we can use from the application or is it > > > > something that > > > > is for debugging diagnostics and may be a best effort? > > > > > > Thomas Monjalon <tho...@monjalon.net> wrote: > > > I think yes it is only for debugging. > > So best effort looks to be a good approach. > > I'm not sure you need to replace the functions. > > Can you just complete the implementations? > > the patch series put forward allows a set / get name per-lcore, where > you get implicit (but not exposed via the eal api) call to underlying > platform thread setname.
I don't understand how lcore ID and thread ID are connected. You can run multiple control threads on a single lcore.
