DragonFly BSD
DragonFly commits List (threaded) for 2005-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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 ...


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 6 May 2005 09:53:19 -0700 (PDT)

    Ok, I understand... it's the on-demand module memory allocation that's
    the issue.

    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
    the kernel.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

: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 
:or a
: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 
:new syscall
:thr_new, the new syscall will setup TLS register for userland, then when 
:first
:userland instruction is executed, the thread's  environment was already 
:fully setup,
: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.
:
:David Xu



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]