Date: Mon, 24 Mar 2014 19:04:05 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Transition path for removing lazy init of thread pointer On Mon, Mar 24, 2014 at 01:49:15PM -0400, Rich Felker wrote: > Phase 1: Initialize the thread pointer at startup, but do not make > anything in musl assume that the thread pointer is valid unless the > [...] Phase 1 is now complete. The intent is that it not break any usage (even on ancient kernels that are unsupported) that was not already broken before, so regression reports would be very appreciated if I'm wrong about that. At this point we now have two mandatory syscalls at startup on most archs (just one where setting the thread pointer is entirely a userspace operation). The second syscall is set_tid_address, and it seems like it should only be needed it pthread_create is being used (to that pthread_join will work), but it serves a second purpose of standing in for gettid() too. We could, however, eliminate it in some cases:x - In static-linked programs that never need to know their own tid and never create threads, it can be skipped. This could be achieved with some weak symbol magic. - Even in dynamic-linked programs, we could defer the tid lookup until it's needed by adding a __gettid() function/macro that looks in the thread structure, and if it finds zero, calls set_tid_address. This might add a few cycles to some synchronization primitives, but we're shaving a good number of cycles now anyway since lazy thread-pointer initialization is gone and we can inline the thread-pointer access in a lot more places. I'd welcome feedback on whether these sorts of optimizations (well, more like tradeoffs than outright optimizations) are desirable. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.