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

[David Xu]

Matthew Dillon wrote:
: (David Xu <davidxu at 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.
Not sure, but there always is exception.

: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.
The management thread should be avoided, that introduces complex into
userland, I don't want to go old evil linuxthread way.
I only need one flag to indicate that the thread now executes in
kernel(pthread_exit() calls _exit()), so its userland resource is no 
longer needed, e.g. its userland stack and user thread control block, so 
other threads can reuse them when creating new thread or recycle it at 
sometime later, but without this flag, there is always a race condition, 
it is not safe to reuse it because that thread may be still using the 
stack, although it called _exit(), but that does not say it is not using 
the stack! calling _exit() pushes return address on stack, and it 
destroys another thread's memory if the stack was reused by other 
threads very quickly.
In detail, I want following feature:
a syscall allows userland to set an userland address, for example:
__sys_set_thread_exit_addr(int *addr), it remembers the addr
in kernel thread structure, if the thread calls _exit(),
in kernel, kernel code writes a value to addr, that's the only
thing I need to do userland garbage collection.
In this way I can avoid complex of management thread.

Cheers,
David Xu