This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Native POSIX Thread Library(NPTL) ARM SupportingPatches (1/3)
- From: Philip Blundell <pb at nexus dot co dot uk>
- To: "Hu, Boris" <boris dot hu at intel dot com>
- Cc: "Libc-Alpha (E-mail)" <libc-alpha at sources dot redhat dot com>, "NPTL list (E-mail)" <phil-list at redhat dot com>
- Date: 29 May 2003 15:15:23 +0100
- Subject: Re: [PATCH] Native POSIX Thread Library(NPTL) ARM SupportingPatches (1/3)
- References: <37FBBA5F3A361C41AB7CE44558C3448E1A1811@pdsmsx403.ccr.corp.intel.com>
On Fri, 2003-05-23 at 09:23, Hu, Boris wrote:
> However, TLS is absent in arm toolchain. So here is a work-around way.
> In the linux kernel, a thread register is simulated by an additional field(pd_addr)
> to thread_struct and two system calls(sys_get/set_thread_area()). __thread
> keyword is disabled in glibc and nptl. Moreover, some code related TLS in nptl
> is protected by the glibc macro USE_TLS.
Thanks for working on this.
I wonder what the performance impact is of having a system call in
THREAD_SELF. If it turns out to be too great, it may be possible to
reduce the overhead by adding some more support to the kernel. What
I've been thinking of is a way for applications to supply a pointer to
the kernel (via a new system call), and have it store the current thread
ID at that address during context switch. That way, retrieving the
thread descriptor would be just a regular memory access. I think it'd
only add a handful of cycles to the context switch path, and that's a
comparatively heavyweight operation already so it would probably
disappear in the noise.