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

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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.
:
:David Xu

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

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>