Re: Transition path for removing lazy init of thread pointer

[Rich Felker <dalias@aerifal.cx>]

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