DragonFly BSD
DragonFly commits List (threaded) for 2005-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: David Xu <davidxu@xxxxxxxxxxx>
Date: Wed, 02 Feb 2005 13:23:56 +0800

Matthew Dillon wrote:
: (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.

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.

David Xu

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