Adam Olsen wrote:
> Killing threads at arbitrary points really is that dangerous.
I'm not talking about killing an arbitrary thread, but
a particular thread that I've designed with the idea of
killing it in mind.
And I'm not really talking about killing it, either,
just having a way of tapping it on the shoulder and
getting its attention whatever it happens to be doing.
I don't believe that's an outrageously unreasonable
thing to want to be able to do.
To be precise, what I have in mind is this:
1) A way of causing an exception to be raised asynchronously
in another thread.
2) Such exceptions would be automatically blocked in
a finally clause.
3) There would be a way of explicitly blocking them
around a section of code, e.g. using a context manager.
4) If it makes anyone feel any better, they could be
blocked by default until explicitly enabled by the
thread concerned.
5) When a thread dies, either:
a) Any locks it is holding are automatically released,
or
b) An exception is raised in the main thread if it dies
while holding any locks (since this indicates a programming
error, i.e. the thread failed to clean up after itself
when receiving an asynchronous exception).
Can anyone point to a reason it would be difficult to write
well-behaved threaded code in the presence of these features?
--
Greg
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
