Killing threads (was Re: Cancel or timeout a long running regular expression)

MRAB python at mrabarnett.plus.com
Sat Sep 17 19:52:15 EDT 2011


On 18/09/2011 00:26, Dennis Lee Bieber wrote:
> On Sun, 18 Sep 2011 07:35:01 +1000, Chris Angelico<rosuav at gmail.com>
> declaimed the following in gmane.comp.python.general:
>
>> Is it just that nobody's implemented it, or is there a good reason for
>> avoiding offering this sort of thing?
>>
> 	Any asynchronous "kill" runs the risk of leaving shared data
> structures in a corrupt state. {Stupid example, but, in pseudo-Python:
>
> import time
>
> class Account(object):
> 	def __init__(self, initial=0.0)
> 		self.balance = initial
>
> myAccount = Account(100.0)
> yourAccount = Account(100.0)
>
> accountLock = threading.Lock()
>
> def threadWork(lock, a1, a2, rate):
> 	while True:
> 		time.sleep(rate)
> 		lock.lock()
> 		t = a2.balance / 2
> 		a1.balance += t
> 		#say a thread.kill kills at this point
> 		a2.balance -= t
> 		lock.release()
>
> # create/start thread1 passing (accountLock, myAccount, yourAccount, 60)
> # create/start thread2 passing (accountLock, yourAccount, myAccount,
> 120)
>
> time.sleep(300)
> thread1.kill()
>
> 	So... Thread1 may be killed after one account gets incremented but
> before the other is decremented... And what happens to the lock? If it
> doesn't get released as part of the .kill() processing, they program is
> dead-locked (and the magically appearing money will never be seen). If
> it does get released, then the sum total of "money" in the system will
> have increased.
>
[snip]
The lock won't be released if an exception is raised, for example, if
'a1' isn't an Account instance and has no 'balance' attribute. Using a
context manager would help in that case.



More information about the Python-list mailing list