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