Stopping threads from the outside

[Andrae Muys]

Boudewijn Rempt <boud at valdyas.org> wrote in message news:<3c9e2692$0$24819$e4fe514c at dreader3.news.xs4all.nl>...
> Peter Hansen wrote:
> 
> > holger at trillke.net wrote:
> >> 
> >> > >how could you stop a running threading.Thread from the *outside*? of
> >> > >course i could introduce some kind of flag into the event loop of the
> >> > >Thread.run-method, but i really would prefer to have a non-instrusive
> >> > >way for several reasons.
> >> > >
> >> > >Any way to do this?
> >> >
> >> > Not really.  Why do you want to do it?
> >> 
> >> You really want to know it? I am currently working
> >> on (coded) agents which move through the network.
> > 
> > "The network"?  Which one?  The Internet, or an internal
> > network over which you have full control?  Who controls
> > the servers on which these agents will be running?
> > 
> >> But of course i'd sometimes like to shut down some or
> >> all agent-threads.
> > 
> > Run them in a separate process and kill the process when
> > it's "sometime"?  If you can live without individual
> > control.  Maybe you can identify groups of them?
> > 
> 
> Actually, Holger's problem is very well known to people
> implementing agents. Agents run within the application, but
> they don't share objects (not often, anyway), so killing them
> is safe. But neither in Java nor in Python you can easily kill
> them.

This is precisely because your assumption that you can "know" threads
don't share objects is an implementation issue.  One critical problem
is the issue of MT-safe libraries.  In both Java and Python threads
will routinely hold implicit shared locks on shared libraries.  Which
functions in which libraries involve implicit locks is naturally
implementation dependent, often including malloc/free and friends.  As
a result there is no platform independant (and often no platform
dependant) way of knowing the precise coupling between two threads. 
Hence no way of implementing a safe async-kill function.

Note that similar problems exist with processes when they use shared
synchronisation.  Consider the common need to clean up flock/.pid
files after SIGKILL'ing unix daemons.  The crucial difference is that
the higher granuality, and the increased isolation (ie. limited damage
domain) of processes allows for safe clean-up of any resulting mess. 
With the higher coupling of a shared-address space implied by threads,
cleaning up the damage caused by async-kill becomes non-trivial.

Andrae Muys