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

[David Xu <davidxu@xxxxxxxxxxx>]

Matthew Dillon wrote:
>     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.
I need fast critical section, otherwise I can just use sigprocmask
everywhere, the critical section has to be per-thread based, a
shared memory page won't work. one thread blocking signal shouldn't
stop other threads to process signal.

> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>

David Xu