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
davidxu at freebsd.org
Wed Feb 2 16:05:08 PST 2005
Matthew Dillon wrote:
:This is fine to me, did you consider how to exit whole process not
:just a single thread ? right now, I am using _exit(), but it only
:exits current thread, other threads can not be shutdown.
The problem with using _exit() to exit all threads is that there
is no way to notify the other threads of the event, and there are
cases where we might want that feature. I think what we want here
is a signal rather then a system call.
Since we are already going to create a distinction in the signal handling
between vectored and shared signals, there is no reason why we couldn't
also create the concept of a 'broadcast' signal, that all threads get.
SIGKILL, SIGSTOP, SIGTSTP, SIGCONT... these would all be broadcast
signals by default.
We would implement it via sigaction(). We would add a SA_BROADCAST
flag to handle broadcast signals, and we would also add a SA_VECTORED
flag to differentiate between shared signals and targeted signals.
-Matt
Matthew Dillon
<dillon at xxxxxxxxxxxxx>
There are problems, first, when debugging, debugger will catch
the signal, second is important, exit() should save a value in
kernel zoombie proc structure, so parent waitpid() on it can get
the exit code, signal can not provide this feature.
Linux has exit_group() which I think is used to implement exit().
FreeBSD introduced thr_exit and kse_exit to exit single thread,
and leave orignal exit() to exit whole process.
David Xu
More information about the Commits
mailing list