cvs commit: src/sys/i386/include tls.h src/gnu/usr.bin/cc34/cc_prep/config dragonfly-spec.h src/gnu/usr.bin/cc34/cc_prep/config/i386 dragonfly.h src/lib/csu/i386 crt1.c src/lib/libc/gen tls.c src/lib/libc/i386/sys cerror.S src/lib/libc/include libc_private.h ...
dillon at apollo.backplane.com
Wed May 11 18:25:35 PDT 2005
:We still have a problem not discussed yet, maybe too hurry here ?
:if we want to put user critical section pointer into the tcb,
:and used by rtld to block user signal handler, what rtld should
:do now ? we have deadlock problem if current thread held reader
:lock, and later it catches a signal and in signal handler it tries
:to access a __thread variable which causes additional tls data
:block to be allocated which needs writer lock. If rtld does not
:setup initial tls, then in rlock or wlock, it has to check if
:tls was setup or not, it will be diffcult because it does not know
:when libc will setup initial tls. What I am thinking is:
:in wlock_acquire() or rlock_acquire, rtld will access critical
:pointer in tcb, and use an atomic operation:
: struct *tcb = tls_get_tcb();
: atomic_inc_int(&tcb->tcb_critical, 1);
:in wlock_release() or rlock_release():
: atomic_inc_int(&tcb->tcb_critical, -1);
: if (tcb->tcb_critical == 0x80000000)
: getpid(); // trigger signal handler.
Well, I wasn't really planning on putting the user critical
section data in the TCB... but now that you bring it up I
don't see why we couldn't do it.
Basically the way I intend to implement the userland critical
section is by creating two procedures in the syscall layer
to enter and exit the userland critical section. That is, as
far as userland is concerned these would be system calls.
But the actual implementation in the syscall layer would not
have to make an actual system call. I was thinking that it
would 'register' a bit of shared memory (not necessarily
TCB related) that both it and the kernel could mess around
There are other reasons for my wanting to do things this way.
There are a ton of things we can put in such a shared
memory segment. The pid, a copy of the current creds,
the current time of day (tick resolution or seconds resolution
only of course), and so on and so forth. For this sort
of use to be portable the userland program and libraries should
not be allowed to directly access the data but instead would
access it via 'fake' system calls in the syscall layer.
<dillon at xxxxxxxxxxxxx>
More information about the Commits