From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10458 Path: news.gmane.org!.POSTED!not-for-mail From: Felix Janda Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH RFC] add pthread_setname_np Date: Thu, 15 Sep 2016 08:00:18 -0400 Message-ID: <20160915120018.GA505@nyan> References: <20160915030216.GA4535@nyan> <20160915032731.GE15995@brightrain.aerifal.cx> <20160915034351.GA4973@nyan> <20160915041716.GF15995@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1473940877 12836 195.159.176.226 (15 Sep 2016 12:01:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Sep 2016 12:01:17 +0000 (UTC) User-Agent: Mutt/1.6.1 (2016-04-27) To: musl@lists.openwall.com Original-X-From: musl-return-10471-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 15 14:01:14 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1bkVLq-0002l5-Bh for gllmg-musl@m.gmane.org; Thu, 15 Sep 2016 14:01:10 +0200 Original-Received: (qmail 3246 invoked by uid 550); 15 Sep 2016 12:01:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3228 invoked from network); 15 Sep 2016 12:01:10 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20160915041716.GF15995@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:10458 Archived-At: Rich Felker wrote: > On Wed, Sep 14, 2016 at 11:43:51PM -0400, Felix Janda wrote: > > Rich Felker wrote: > > > > Thanks for the review! > > > > > On Wed, Sep 14, 2016 at 11:02:16PM -0400, Felix Janda wrote: > > > > gdb's "info threads" displays the thread name. > > > > --- > > > > Should this function care about interrupted syscalls? > > > > > > Unless it's specified not to return EINTR I'm fine with it returning > > > EINTR. > > > > ok. Is it possible that write() is interrupted with partial data > > written (so that it won't return -1)? > > That won't happen with these proc pseudo-files because the write is > required by the kernel to be atomic. If it's broken up into multiple > parts, the kernel only uses the last one. Thanks for explaining this! So the current function will notice that it is interrupted, and return EINTR. > > > > include/pthread.h | 1 + > > > > src/thread/pthread_setname_np.c | 21 +++++++++++++++++++++ > > > > 2 files changed, 22 insertions(+) > > > > create mode 100644 src/thread/pthread_setname_np.c > > > > > > > > diff --git a/include/pthread.h b/include/pthread.h > > > > index 3d2e0c4..94ef919 100644 > > > > --- a/include/pthread.h > > > > +++ b/include/pthread.h > > > > @@ -214,6 +214,7 @@ struct cpu_set_t; > > > > int pthread_getaffinity_np(pthread_t, size_t, struct cpu_set_t *); > > > > int pthread_setaffinity_np(pthread_t, size_t, const struct cpu_set_t *); > > > > int pthread_getattr_np(pthread_t, pthread_attr_t *); > > > > +int pthread_setname_np(pthread_t, const char *); > > > > int pthread_tryjoin_np(pthread_t, void **); > > > > int pthread_timedjoin_np(pthread_t, void **, const struct timespec *); > > > > #endif > > > > diff --git a/src/thread/pthread_setname_np.c b/src/thread/pthread_setname_np.c > > > > new file mode 100644 > > > > index 0000000..b7f7a4b > > > > --- /dev/null > > > > +++ b/src/thread/pthread_setname_np.c > > > > @@ -0,0 +1,21 @@ > > > > +#include > > > > +#include > > > > +#include > > > > + > > > > +#include "pthread_impl.h" > > > > + > > > > +int pthread_setname_np(pthread_t thread, const char *name) > > > > +{ > > > > + int fd, status = 0; > > > > + char f[sizeof "/proc/self/task//comm" + 7]; > > > > > > Where does 7 come from? I don't think it's correct. 3*sizeof(int) is > > > the normal lazy bound we use for %d's. > > > > man 5 proc > > > > says that the maximum value for a pid is about 4 million. I'm fine with > > to changing it to the usual lazy bound, though. > > Ah. That may be true for all current versions of Linux, but I don't > think it counts as part of the API/ABI. The ABI limit on pids is 512M > IIRC (because high bits have special meaning in robust/PI futex ABI). Ok, better play it safe. Will post an updated patch later Felix