DragonFly commits List (threaded) for 2005-05
Re: cvs commit: src/lib/libc/gen Makefile.inc errlst.c src/lib/libc/i386/sys cerror.S ptrace.S src/lib/libc/sys Makefile.inc __error.c src/lib/libc_r/sys Makefile.inc uthread_error.c src/lib/libc_r/uthread Makefile.inc ...
Ok, I understand... it's the on-demand module memory allocation that's
errno will be safe then, but we have to solve the signal locking issue
before we can deploy __thread significantly outside of libc.
The RTLD itself does not use TLS... it has its own statically linked
libc and thus its own private errno. So at least we don't have to worry
about that aspect of the problem.
I very much want to implement the signal critical section for
userland in userland, but I want to do it right and that means having
the compatibility layer that can do the shared memory negotiation with
:In general, the commit is fine. however, because the tls implementation is
:not signal safe, accessing __thread based variable in signal handler will
:cause rtld to try to get writer lock if the tls space is never allocated
:new shared library was loaded, but the thread may have already gotten
:a reader lock in rtld to resolve a symbol, so thread will wait for itself to
:release the reader lock, then deadlock happens.
:Another problem within current libthread_xu implementation is that
:profiling version libthread_xu_p.so may not work reliably, because .mcount()
:will execute before a thread setup it TLS register because rfork() can
:not set TLS
:register for new thread. it is fixed in FreeBSD -current by introducing
:thr_new, the new syscall will setup TLS register for userland, then when
:userland instruction is executed, the thread's environment was already
:there is no sigprocmask() call etcs to avoid the race condition which really
:can not avoid all the races.
:I don't know if it is safe to let rtld use __thread errno, if rtld is
:also built with
:the new libc, any syscall in rtld will also use the new errno style.