How to force a thread to stop

[olsongt at verizon.net]

Carl J. Van Arsdall wrote:
> Jean-Paul Calderone wrote:
> > On Mon, 24 Jul 2006 11:22:49 -0700, "Carl J. Van Arsdall" <cvanarsdall at mvista.com> wrote:
> >
> >> Steve Holden wrote:
> >>
> >>> Carl J. Van Arsdall wrote:
> >>> [... rant ...]
> >>>
> >>>
> >>>> So with this whole "hey mr. nice thread, please die for me" concept gets
> >>>> ugly quickly in complex situations and doesn't scale well at all.
> >>>> Furthermore, say you have a complex systems where users can write
> >>>> pluggable modules.  IF a module gets stuck inside of some screwed up
> >>>> loop and is unable to poll for messages there's no way to kill the
> >>>> module without killing the whole system.  Any of you guys thought of a
> >>>> way around this scenario?
> >>>>
> >>>>
> >>>>
> >>>>
> >>> Communications through Queue.Queue objects can help. But if you research
> >>> the history of this design decision in the language you should discover
> >>> there are fairly sound rasons for not allowing arbitrary "threadicide".
> >>>
> >>>
> >>>
> >>>
> >> Right, I'm wondering if there was a way to make an interrupt driven
> >> communication mechanism for threads?  Example: thread receives a
> >> message, stops everything, and processes the message.
> >>
> >>
> >
> > And what happens if the thread was halfway through a malloc call and
> > the data structures used to manage the state of the heap are in an
> > inconsistent state when the interrupt occurs?
> >
> > This has been discussed many many times in the context of many many
> > languages and threading libraries.  If you're really interested, do
> > the investigation Steve suggested.  You'll find plenty of material.
> >
>
> I've been digging around with Queue.Queue and have yet to come across
> any solution to this problem.  Queue.Queue just offers a pretty package
> for passing around data, it doesn't solve the "polling" problem.  I
> wonder why malloc()'s can't be done in an atomic state (along with other
> operations that should be atomic, maybe that's a question for OS guys, I
> dunno).  Using Queue.Queue still puts me in a horribly inflexible
> "polling" scenario.  Yea, I understand many of the reasons why we don't
> have "threadicide", and why it was even removed from java.  What I don't
> understand is why we can't come up with something a bit better.  Why
> couldn't a thread relinquish control when its safe to do so?  While the
> interpreter is busy doing malloc()s a thread receives a control message,
> the thread waits until it knows its no longer in an atomic state and
> gives control to the message handler when it can.  Its about setting up
> a large system that is controllable without the painstaking process of
> putting message polling loops all over the place.  Main threads in a
> python program can setup a signal handler, accept signals, and that
> signal can happily go ahead and kill a python interpreter.  Why can't
> this concept be taken farther and introduced into threading?
>
> There is no system that is completely interruptible, there will always
> be a state in which it is not safe to interrupt, but many systems work
> around this just fine with cautious programming.  Has anyone considered
> an event driven approach to sending control messages to threads?
>
> -c
>


Have you looked at stackless yet?

You can do all kinds of crazy stuff like infinitely suspending a
tasklet (stackless' version of threads) and effectively killing it,
sending messages via channels that can be externally monitored, send
arbitrary exceptions that are immediately raised in other tasklets,
writing your own pre-emptive schedules, saving a tasklet on disk for
later examination, etc, etc.