[Bug 200138] [PATCH] Fixed per-thread 'specific' array allocation conflict incurred in libthr by some foreign malloc libraries
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Fri May 15 08:41:19 UTC 2015
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200138
--- Comment #20 from commit-hook at freebsd.org ---
A commit references this bug:
Author: kib
Date: Fri May 15 08:40:18 UTC 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 at rawbw.com
PR: 200138
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Changes:
head/lib/libthr/thread/thr_spec.c
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-threads
mailing list