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:
> :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.
> :
> :David Xu
>
>     Well, each thread could have its own block of memory.  But that could
>     add up fairly quickly.
I don't think it is cheap on x86 architecture.

>     A TCB based critical section is certainly reasonable, and easy for the
>     kernel to access.
Yes.
>     Another option would be to implement a code path critical section.
>     Basically we would inform the kernel not to interrupt userland if
>     the userland instruction pointer is within a specified range of
>     addresses.  This would also be easy to implement.
I don't like the idea. Thread library also wants to use the critical
region, and maybe .mcount() based profiling code also wants this.

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

David Xu