Re: help with pthread_t deprecation / api changes

[Thomas Monjalon <thomas@monjalon.net>]

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 <thomas@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 <thomas@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.