hey, combining the reply to both Thomas and Stephen since i think this series http://mails.dpdk.org/archives/dev/2022-December/257238.html addresses both feedback comments.
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. the intent here is if you have it and it works you'll get it and if you don't you won't but the eal doesn't force the application to deal with it conditionally on a per-platform basis. > Stephen wrote: > > Surprisingly, thread names are not preserved in core dumps. > The core dump standard used by Linux does not put thread name in the image. > Since this is a ELF ABI unlikely to be ever be added. the patchset addresses this by actually keeping a copy of the name set, so it will be available in the coredump. the intent here is to make it available for use by the application i.e. get that works on all platforms, but also you can actually pull the name out under a debugger or a dump and does not require any conditional dancing per-platform by the application. as an aside there are 2 series up for review that finally clean the remaining platform-specific thread references from the eal public interface. http://mails.dpdk.org/archives/dev/2022-December/257238.html http://mails.dpdk.org/archives/dev/2022-December/257413.html the set get name api patch series i'm preparing a v2 for due to some minor things caught by the ci and an issue with mingw but otherwise if we can get these in it will unblock a lot of the internal detail cleanups we've been trying to accomplish. really appreciate it guys. thanks.
