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 ...
Matthew Dillon wrote:
:No, both DragonflyBSD and FreeBSD's tls implementation are notIn general, the commit is fine. however, because the tls implementation is
:asynchronous signal safe yet, also I did try to support it
:in rtld, but it still does not work correctly, because reader
:lock in rtld does not disable signal.
:I think this change should be delayed, otherwise it will cause
:a dead lock in signal handler.
:I remembered I ever told Matt that a fast userland critical section
:is needed, I just don't have enough time to follow the Dragonfly
:development speed, sorry for that.
Yes, I still want to do that.
I'm a little confused over the problem with Joerg's commit. What
exactly does it break that wasn't broken before?
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.