Re: cvs commit: src/lib/libthread_xu Makefile pthread.map src/lib/libthread_xu/arch Makefile.inc src/lib/libthread_xu/arch/alpha Makefile.inc src/lib/libthread_xu/arch/alpha/alpha pthread_md.c src/lib/libthread_xu/arch/alpha/include pthread_md.h src/lib/libthread_xu/arch/amd64 ...

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: (David Xu <davidxu@xxxxxxxxxxx> writes)
:A signal thread will be a bottleneck, and a well written thread
:application may use sigwait(), that means application will create
:signal thread by itself, having a signal thread in kernel will introduce

    How many threaded programs use signals heavily?  I can't think of a
    single one.  We only have to make it work, we don't have to make
    it efficient.

:SIGSTOP should suspend all threads in same process,  in Dragonfly,
:will it need IPI to suspend threads on other CPUs ? also SIGCONT
:should resume all threads suspended by SIGSTOP, SIGTSTP etcs...,
:it might need IPI request and ack code...

    Some of this nature, yes.  When multiple processes contexts have to
    be acted upon the actions must occur on the same cpu that the contexts
    are running on or controlled by.  But again, this mechanism does not
    have to be efficient.

:I would like there is a new syscall to remember a userland address
:in kernel, when the thread exits in kernel, kernel will write out
:a value in that address, and do umtx_wakeup on the address, this
:simulates pthread_join, a joiner just waits at that address via
:umtx_sleep. Or like thr_exit() in FreeBSD, it writes out a value for
:given address, and do umtx_wakeup (not implemented in FreeBSD)
:for that address, current I do a umtx_wakeup in pthread_exit(),
:please reference code in thread/thr_exit.c and thread/thr_join.c

    I don't think it's necessary to get the kernel involved too much.
    Cleaning resources up after an exiting thread is trivial, you just
    queue a message and synchronously switch to another 'management' user 
    thread context (running in the same rfork cpu context) which is 
    independant of the one that is trying to exit.  The management thread
    can clean up after the one trying to exit.

    For a physical rfork process exit the standard wait4/waitpid mechanism,
    suitably enhanced (since the pid would no longer be a differentiator),
    would be sufficient to allow one of the other rfork's to clean up after
    the first one, or to terminate the rest of the application.

:I would like implement it in GDT. the detail is like sysarch()
:syscall on i386, a new syscall allows user code to save two or
:three segment descriptors in thread MD part structure,
:and in context switch routines,  the switch code copy
:these segment descriptors into GDT table, one entry only needs
:8 bytes, 3 entries only needs 24 bytes, it is easy to do, then
:there is no limit on how many threads can be created, using
:LDT, one can only create 8192 threads on x86, while other
:architectures do not have such limits, in fact, on AMD64,
:CPU supports set GS base and FS base, TLS implementation
:has to use these instructions, on i386, using GDT is simulating
:the AMD64 behaviour.

    I think that is is reasonable to implement kernel-supported GDT
    switching.  Sounds like a reasonable plan.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

:There is a document about tls:
:http://people.redhat.com/drepper/tls.pdf