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

From: David Xu <davidxu@xxxxxxxxxxx>
Date: Thu, 12 May 2005 09:54:06 +0800

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

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.

Matthew Dillon <dillon@xxxxxxxxxxxxx>

David Xu

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