is it safe to stop a thread?

[Eric Lee Green]

-----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 :-(. 

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
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
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).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7C1WU3DrrK1kMA04RAnQUAJ4ni9RJnqNWTP18UBxFF8jynzyq2gCfVSb0
/wvU/vhJ1qX221H5mb1+yeI=
=JsdM
-----END PGP SIGNATURE-----