[Python-3000] threading, part 2
Jason Orendorff
jason.orendorff at gmail.com
Fri Aug 11 17:47:39 CEST 2006
On 8/11/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> why is thread.raise_exc(id, excobj) a bad API?
It breaks seemingly innocent code in subtle ways. Worse, the breakage
will always be a race condition, so it'll be especially hard to
reproduce and debug.
class Foo:
...
def close(self):
self.f.close()
self.closed = True
Any code that uses the "closed" attribute obviously depends on it
being properly set, right? This close() method gets this right. It
sets "closed" if and only if the self.f.close() call succeeds. There
are circumstances where this will fail: MemoryError,
KeyboardInterrupt, a broken trace function, a broken __setattr__(),
del __builtins__.True... but all are extreme cases. I think
thread.raise_exc() should be considered extreme too. Otherwise, its
existence must be considered to degrade the reliability of the above
code.
I'm not saying "don't add this". Maybe it's useful, particuarly as a
fallback mechanism for killing a runaway thread. But it should be
documented as an extreme measure.
-j
More information about the Python-3000
mailing list