Killing threads
Gary E. Miller
gem at rellim.com
Tue Sep 27 19:26:22 UTC 2016
Yo Daniel!
On Tue, 27 Sep 2016 15:16:55 -0400
Daniel Franke <dfoxfranke at gmail.com> wrote:
> On 9/27/16, Gary E. Miller <gem at rellim.com> wrote:
> > There is more than one way to 'kill' a thread. The nice way is to
> > 'kill -HUP', which politely tells the thread to commit seppuku in
> > the cleanest way the thread knows how.
>
> Sure, but the default signal handler for that just terminates the
> thread immediately and leaves it in a likely-unsafe state. A thread
> can install its own signal handler, but the only safe/sane way to
> implement one is to have the handler set a condition variable
> which the thread then checks for periodically and cleans up if it
> finds it set.
Yes.
> 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...
> Just have the parent thread set the condition variable directly,
> then join on the child and wait while it cleans up.
As a start, yes, but that leaves unsolved the other important cases I
just stated.
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/2a1251bc/attachment.bin>
More information about the devel
mailing list