Killing threads

Gary E. Miller gem at rellim.com
Tue Sep 27 20:34:05 UTC 2016


Yo Daniel!

On Tue, 27 Sep 2016 15:34:46 -0400
Daniel Franke <dfoxfranke at gmail.com> wrote:

> On 9/27/16, Gary E. Miller <gem at rellim.com> wrote:
> > On Tue, 27 Sep 2016 15:16:55 -0400
> > Daniel Franke <dfoxfranke at gmail.com> wrote:  
> >> But in that case, what's the point of using signals?  
> >
> > So the user can also niely terminate a thread.  Or so a system
> > shutdown can nicely terminate the thread.Or if the msater thread
> > already crashed. Or the thread is stuck in an infinite loop and not
> > checking the shutdown condition variable.  Or the thread is stuck
> > in a system call that is not returning.  Or...  
> 
> In the first two cases you just want to kill the entire process. So
> the user (or initd) sends a signal to the process, and the signal
> handler calls exit(2) and every thread terminates at once, thus
> there's no concern about inconsistency because the whole heap is
> getting deallocated.

There are things like system semaphores that you may want to
remove before quiting.  This is a huge problem in apache, you can't
just kill it, you need to let it release system resources.  If you
kill it, you eventually run out of ipcs.

> In all the latter cases, you might *wish* you
> could just kill one thread, but nonetheless killing the whole process
> is the only safe course of action because your heap is trashed and
> there's no reliable way to repair it.

Once again, in Apache at least, there can be good reasons for just killing
a rogue thread.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160927/7a47edad/attachment.bin>


More information about the devel mailing list