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