Stopping threads from the outside

[holger at trillke.net]

> > Peter Hansen wrote:
> > > Yes, that's the case.  It's generally considered to lead to
> > > undefined behaviour if you do manage to kill a thread from
> > > the outside, because of resource locking issues and such.
> > 
> > That's the received opinion indeed. It still leads to problems.
> > I mean -- it's why you can kill a process, but not a thread. But in
> > an agent system, every agent (presumably running a thread, although
> > I've implemented systems where agents share threads, cooperative
> > multi-tasking agents) is on its own, and shouldn't own objects
> > or locks.
> 
> I'm curious what the agent actually does if it doesn't share
> anything.  Does it not take input?  And produce output?
> No opening files, accessing Queues and such?  If it does
> any of those things, wouldn't that make it potentially a
> problem if you killed it?

Well. my agents share a namespace (named share:-) through which they
can get to one another. 

You don't neccessarily need to brutally kill the thread without 
the running code in that thread to notice it. Something like this 
would be nice:

def run(self): # thread's run
    try:
        while something:
            do_something()
    except ThreadInterruptException,e:
	niceley_free_locked_resources_or_such()

or "simply" let the python interpreter switch the
program flow to "destroy(self)" or so. This might require
the thread to notify external modules e.g. a mt-safe Queue
that all locks associated with this thread are
to be released. But it would help. And somehow i think
the interpreter must know about the threads as it is 
managing it (e.g. the global interpreter lock). So this
should be possible?

I don't know if this run-method would be possible if the thread
sits in socket.accept() or such. But this issue has not much
to do with locked resources hanging around.

	holger