Killing threads

Marcin 'Qrczak' Kowalczyk qrczak at knm.org.pl
Mon Mar 19 02:31:56 EST 2001


Fri, 16 Mar 2001 19:27:39 +0100, Steve Purcell <stephen_purcell at yahoo.com> pisze:

> Thread cancellation is generally considered a bad thing. If I'm
> not mistaken, the argument against allowing thread cancellation is
> concerned with correctly releasing locks shared between threads.

In Glasgow Haskell a thread can block and unblock asynchronous
exceptions, which includes killing it. So you get the ability to kill
arbitrary computation while important sections can be protected.

The interface of block and unblock is that these functions take a
computation as an argument, so they restore the blocking state after a
computation finished. In Python they would have to be plain imperative
statements instead, to be used thus (ignoring the restoration):
    try:
        thread.block()
        ...
    finally:
        thread.unblock()

Actually killing a thread is in fact throwing an exception to it.
except: and finally: clauses are executed up to the point when the
thread was created. In this case maybe just try:finally: could be
used to release locks without having explicit block and unblock.

In Glasgow Haskell you automatically get a lock around the equivalent
of finally: clause (it's a function which uses block and unblock
internally).

Disclaimer: I don't have much experience in programming with threads.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK



More information about the Python-list mailing list