Stopping threads from the outside

[holger at trillke.net]

> Your "agents" sound a lot more like they are just threads,
> but maybe I don't see the distinction.  From the above 
> description, I think you'll have other problems on your hands
> than just terminating the threads.  You've got what appears
> to be a very highly coupled system (...)

In this case, yes. The point is that my agents don't need
to behave to any framework. The only change in programming 
paradigms should be that you have to really think your
Classes/Objects as "self-responsible". They can use the protocol
of their choice (i provide a very simple one) to transfer themselves
to other systems. Or someone else transfers them with a specific protocol.

The Agent "servers" don't do much on themselves
but instead leave it to agents to provide "framework" and protocol
capabilities. So to decouple the agents i would probably
introduce a "RelationShip"-Agent managing couplings between
them.

In the mentioned case the agents work
as threads because that makes sense for their task. There 
are also some "passive" agents which don't "live" on their own (thread).
For example the "Config-Agent" or the "scanning directories"
agent :-) These are quite similar to "modules".

> The approach I suggested in my other reply would still work
> nicely if you can ensure the threads call through an intermediary
> instead of directly into each other.  You might also try 
> a low-performance hack until you have time to implement the
> modification in the interpreter :-), which would be to
> stick a flag check into a routine inserted with sys.settrace().
> Have that routine raise the exception if the flag is set for
> the current thread...

interesting suggestion! Doesn't this cause a lot of overhead unless
done in C?  (checking for thread_id and if there is a flag set for it
for each python-instruction)

thanks again,

	holger