Date: Fri, 15 May 2015 18:31:36 -0700 From: Rui Paulo <rpaulo@me.com> To: Konstantin Belousov <kib@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r282948 - head/lib/libthr/thread Message-ID: <2876732.7TSEeLUW1T@akita> In-Reply-To: <201505150840.t4F8eHhM000804@svn.freebsd.org> References: <201505150840.t4F8eHhM000804@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 15 May 2015 08:40:17 Konstantin Belousov wrote: > Author: kib > Date: Fri May 15 08:40:17 2015 > New Revision: 282948 > URL: https://svnweb.freebsd.org/changeset/base/282948 > > Log: > Some third-party malloc(3) implementations use pthread_setspecific(3) > to handle per-thread information. Since our pthread_setspecific() > implementation calls calloc(3) to allocate per-thread specific data > storage, things get complicated. > > Switch the allocator to use bare mmap(2). There is some loss of the > allocated page, since e.g. on amd64, PTHREAD_KEYS_MAX * sizeof(struct > pthread_specific_elem) is 3K (it actually spans whole page due to > padding), but I believe it is more acceptable than additional code for > specialized allocator(). > > The alternatives would either to make the specific data array be part of > the struct thread, or use internal bindings to call the libc malloc, > avoiding interposing. > > Also do the style pass over the thr_spec.c, esp. simplify the > conditionals nesting by returning early when an error detected. > Remove trivial comments. > > Found by: yuri@rawbw.com > PR: 200138 > Sponsored by: The FreeBSD Foundation > MFC after: 2 weeks Thanks! I think umem might be affected as well. -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2876732.7TSEeLUW1T>