is it safe to stop a thread?

[Ype Kingma]

Eric Lee Green wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 23 May 2001 04:54:46 GMT, Parzival Herzog <parz at home.com> wrote:
> >Past posts on this group have suggested that the
> >subject thread should poll for an indication
> >that it should stop itself, and that one thread
> >trying to stop another thread from another is
> >a sign of poor design.
> >
> >I would disagree, and ask if anyone can offer a
> >more rational explanation why Python threads
> >are designed to be not stoppable (if I am not
> >mistaken about this.)
> 
> thread a grabs the semaphor protecting the global socket.
> thread b kills thread a.
> thread c tries to grab the semaphor protecting the global socket.
> 
> *DEADLOCK!*.
> 
> Now, there's the possibility of creating a semaphor wrapper class that
> when you request the global semaphor, it can detect that thread a has died,
> and give the semaphor to thread c. Unfortunately, there's no
> standard way to know if a particular thread is still alive or not. For
> example, on FreeBSD a thread runs within the parent process, while on
> Linux a thread has is just a process that happens to share its memory
> space with another process.
> 
> The only way I've really found of doing this is shared memory and processes,
> where it is Posixly positive that you can detect that a process has died.
> Unfortunately, Python is excruitiatingly painful when using the Posix
> shared memory model :-(.

You can set a threading.event() in the last finally clause of the thread,
see below.

> 
> Threads are evil. They are evil, wicked, nasty things. They are evil,
> wicked nasty things because there's no easy way to free the resources
> that a thread has allocated if the thread dies or is killed, unless
> you do some very tedious book-keeping. I thought doing that tedious

This bookkeeping is not at all tedious in Python.
A thread exits by raising an exception. This means that all
pending finally clauses _will_ be executed:

exitEvent = threading.Event()
f = open(filename)
try:
    someCodeThatMightCallExit() # and thereby raise the thread exit exception
finally:
    f.close()
    exitEvent.set()

> book-keeping was why operating systems were invented, especially the
> whole notion of a "process", where the allocated resources are
> automagically de-allocated when the process dies. Unfortunately, some

Hmmm, an OS in python?

> beknighted notion of "efficiency" has made threading the de-facto
> "standard" on most platforms for programs that must do multiple tasks,
> even though, on Linux at least, a thread spawn and a process fork are
> the exact same freakin' kernel call (just a different parameter), and
> take virtually the same amount of time (both create a copy of the page
> tables, the only big difference is that the process fork sets the
> copy-on-write flags for the pages).

You can do a sys.exit() and leave the cleanup to your favourite OS.
I prefer to reserve that for the main thread after
it has detected that all other threads have exited.

FWIW: the python thread model is very close to the java thread model:

  http://java.sun.com/j2se/1.3/docs/api/java/lang/Thread.html

and for more on the problems of killing threads:

  http://java.sun.com/j2se/1.3/docs/guide/misc/threadPrimitiveDeprecation.html

I think the similarity is no coincidence, but I don't know anything about the
history of python threads. The similarity probably saved a lot of 
headaches for implementing JPython threads.

Regards,
Ype

-- 
email at xs4all.nl

exitEvent.wait()
sys.exit()