Date: Tue, 12 May 2015 11:12:49 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 200138] [PATCH] Fixed sthread-specific array allocation conflict incurred in libthr by some foreign malloc libraries Message-ID: <bug-200138-16-egZcEJyo86@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-200138-16@https.bugs.freebsd.org/bugzilla/> References: <bug-200138-16@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200138 --- Comment #10 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to yuri from comment #8) Requirements for the malloc interposers are established by the system source code. Third-party malloc library has to adhere to the constraints put by the system, if the intent is to replace the system component. I am saying that your statements do not make sense exactly because they do not make sense. The mere fact that a patch results in not printing a message, does not make the patch valid. That said, I think it would be more useful to ease the life of malloc(3) interposers by avoiding the calloc call in the pthread_setspecific(3). The size of the thread-specific is around 1K per thread, which is almost free for the userspace to carry together with the struct thread. Non-trivial threading programs would use explicit TLS for sure. Try the patch I am attaching. I change specific to be a part of the struct thread, and also I cleaned style and removed false or trivial comments. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-200138-16-egZcEJyo86>