From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AC5D7A00C5; Fri, 9 Dec 2022 21:06:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 47D85410FB; Fri, 9 Dec 2022 21:06:16 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id AAF6C40A8B for ; Fri, 9 Dec 2022 21:06:14 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id C315720B6C40; Fri, 9 Dec 2022 12:06:13 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com C315720B6C40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1670616373; bh=54RMNdDQgAIsUsweTSyBdlkt+gMyfMV8k4TGWxW6ezY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NCOFeIUbX+imSHRRNMP5K5+vPL7pMzk77FfLG/gggXgWjv5vCFiBq6xIzeIwt9ZOV L0y9PDNDc6OpRLo5OEFH/K3LAwqOXB8bP+WNSwZodM/SOsRvcbyfu9cdf1FWGwmQe8 oDuZZM6vLWF7vNmYOSYTeyb0TB3J44eVGNMe4eLw= Date: Fri, 9 Dec 2022 12:06:13 -0800 From: Tyler Retzlaff To: Stephen Hemminger Cc: Thomas Monjalon , Morten =?iso-8859-1?Q?Br=F8rup?= , dev@dpdk.org, david.marchand@redhat.com, Bruce Richardson Subject: Re: help with pthread_t deprecation / api changes Message-ID: <20221209200613.GB19263@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20221130225427.GA13682@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D8753E@smartserver.smartshare.dk> <20221202195750.GA28809@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <2146119.C4sosBPzcN@thomas> <20221209084814.3b1479d5@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221209084814.3b1479d5@hermes.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 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 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.