On Thu, 15 Mar 2007 09:41:31 -0500, skip@pobox.com wrote:

...

...

I just proposed to implement thread cancellation for the SoC. Is there any prior work where one could start?

Jean-Paul> The outcome of some prior work, at least:

Jean-Paul> http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.ht...

I responded to that. I got the impression reading that page that the killed thread doesn't regain control so it can't clean up its potentially inconsistent data structures.

The second question on the page: Couldn't I just catch the ThreadDeath exception and fix the damaged object? Addresses this.

I inferred from Martin's proposal that he expected the thread to be able to catch the exception. Perhaps he can elaborate on what cleanup actions the dying thread will be allowed to perform.

Perhaps he can. Hopefully, he can specifically address these points: 1. A thread can throw a ThreadDeath exception almost anywhere. All synchronized methods and blocks would have to be studied in great detail, with this in mind. 2. A thread can throw a second ThreadDeath exception while cleaning up from the first (in the catch or finally clause). Cleanup would have to repeated till it succeeded. The code to ensure this would be quite complex. Jean-Paul

Martin v. Löwis wrote:

asynchronous exceptions in a sensible way. I have to research somewhat more, but I think the standard solution to the problem in operating system (i.e. disabling interrupts at certain points, explicitly due to code or implicitly as a result of entering the interrupt handler) may apply.

Two already working schemes, that are similar, comes to my mind. One is signals in Linux/Unix, where you can send SIGTERM, and the process can handle it and do whatever it takes. But also you can send SIGKILL, which can not be blocked. The other is microprocessors, where you have interrupts, and when the interrupt is received, you disable it (are there processors that support "reentrant" interrupts? I don't know of any, but I'm no specialist here). To me, is natural this behaviour: One can send ThreadDeath to the thread, and it can handle it or no. If not, it dies. If yes, it does some stuff and dies. But if I send a second ThreadDeath to the same thread, when it's still "dying", for me it's ok to receive an answer like "Ok, ok, I heard you, I'm on it". But, in that scenario, should be a way to say to the thread "Die, die now, no matter what"? Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

On 04:24 pm, martin@v.loewis.de wrote:

Jean-Paul Calderone schrieb:

...

...

I inferred from Martin's proposal that he expected the thread to be able to catch the exception. Perhaps he can elaborate on what cleanup actions the dying thread will be allowed to perform.

Perhaps he can. Hopefully, he can specifically address these points:

1. A thread can throw a ThreadDeath exception almost anywhere. All synchronized methods and blocks would have to be studied in great detail, with this in mind.

2. A thread can throw a second ThreadDeath exception while cleaning up from the first (in the catch or finally clause). Cleanup would have to repeated till it succeeded. The code to ensure this would be quite complex.

Clearly, a thread need to have its finally blocks performed in response to a cancellation request. These issues are real, however, they apply to any asynchronous exception, not just to thread cancellation.

To be sure, the problem does apply to all asynchronous exceptions. That's why it is generally understood that a program which has received an asynchronous exception cannot continue.

In Python, we already have an asynchronous exception: KeyboardInterrupt. This suffers from the same problems: a KeyboadInterrupt also can occur at any point, interrupting code in the middle of its finally-blocks. The other exception that is nearly-asynchronous is OutOfMemoryError, which can occur at nearly any point (but of course, never occurs in practice).

KeyboardInterrupt and MemoryError share a common feature which forced thread termination does not: nobody reasonably expects the program to keep running after they have been raised. Indeed, programs are written with the expectation that MemoryError will never occur, and if it does, the user is not surprised to find them in an inconsistent state. In any situation where a MemoryError may reasonably be expected - that is to say, a specific, large allocation of a single block of memory - it can be trapped as if it were not asynchronous. Long-running Python programs which expect to need to do serious clean-up in the face of interrupts, in fact, block KeyboardInterrupt by registering their own interrupt handlers (Zope, Twisted). Developers who think they want thread cancellation inevitably believe they can, if they are "sufficiently careful", implement operating- system-like scheduling features by starting arbitrary user code and then providing "terminate", "pause", and "resume" commands. That was the original intent of these (now removed) Java APIs, and that is why they were removed: you can't do this. It's impossible. Asynchronous exceptions are better than immediate termination because they allow for code which is allocating scarce or fragile resources to have a probabilistically better chance of cleaning up. However, nobody writes code like this: def addSomeStuff(self, volume, mass): self.volume += volume try: self.mass += mass except AsynchronousInterrupt: while 1: try: self.volume -= volume break except AsynchronousInterrupt: pass and nobody is going to start if the language provides thread termination. Async-Exception-Safe Python code is, and will be, as rare as POSIX Async-Safe functions, which means at best you will be able to call a thread cancellation API and have it _appear_ to work in some circumstances. In any system which uses Python code not explicitly designed to support asynchronous exceptions (let's say, the standard library) it will be completely impossible to write correct code. I'm not a big fan of shared-state-threading, but it does allow for a particular programming model. Threading provides you some guarantees. You can't poke around on the heap, but you know that your stack, and your program counter, are inviolate. You can reason about, if not quite test, the impact of sharing a piece of state on the heap; its destructive methods need to be synchronized along with the read methods that interact with it. Asynchronous exceptions destroy all hope of sanity. Your program might suddenly perform a nonlocal exit _anywhere_ except, maybe, inside a "finally" block. This literally encourages some people that program in environments where asynchronous exceptions are possible (.NET, in particular) to put huge chunks of application code inside finally blocks. They generally look like this: try {} finally { // entire application here } because that is really the only way you can hope to write code that will function robustly in such an environment.

So yes, it would be good if Python's exception handling supported asynchronous exceptions in a sensible way. I have to research somewhat more, but I think the standard solution to the problem in operating system (i.e. disabling interrupts at certain points, explicitly due to code or implicitly as a result of entering the interrupt handler) may apply.

For one thing, the Python core code is not operating system kernel code and it is unlikely that the techniques found there will apply. Interrupts, in particular, are nothing at all like exceptions, and have a completely different impact on running code (which, since it is kernel code, is written much more carefully and under an entirely different set of constraints than Python application, or even framework, code). Can you suggest any use-cases for thread termination which will *not* result in a completely broken and unpredictable heap after the thread has died? If you can think of such a case, are you sure it wouldn't be better served by a set of threads communicating over queues and sending 'Stop' objects to each other to indicate termination at a point in queue rather than a forced termination via exception? Just in case it's not clear from the other things I've said: this is a terrible, terrible idea, and I am shocked that it is even being *considered* for inclusion in Python. As a foolish youth, I wasted many months trying to get a program that used Java's (then not deprecated) asynchronous exception APIs to behave properly. It wasn't possible then, and it isn't possible now.

glyph@divmod.com wrote:

Can you suggest any use-cases for thread termination which will *not* result in a completely broken and unpredictable heap after the thread has died?

Suppose you have a GUI and you want to launch a long-running computation without blocking the user interface. You don't know how long it will take, so you want the user to be able to cancel it if he gets bored. There's no single place in the code where you could put in a check for cancellation. Sprinkling such checks all over the place would be tedious, or even impossible if large amounts of time are spent in calls to a third-party library that wasn't designed for such things. Interaction with the rest of the program is extremely limited -- some data is passed in, it churns away, and some data is returned. It doesn't matter what happens to its internal state if it gets interrupted, as it's all going to be thrown away. In that situation, it doesn't seem unreasonable to me to want to be able to just kill the thread. I don't see how it could do any more harm than using KeyboardInterrupt to kill a program, because that's all it is -- a subprogram running inside your main program. How would you handle this situation?

If you can think of such a case, are you sure it wouldn't be better served by a set of threads communicating over queues and sending 'Stop' objects to each other

If the thread is guaranteed to return to reading from the queue within a bounded time, that's fine, and it's the solution I would recommend in that case. But not all cases are like that. -- Greg

Josiah Carlson wrote:

Greg Ewing wrote:

...

glyph@divmod.com wrote:

...

Can you suggest any use-cases for thread termination which will *not* result in a completely broken and unpredictable heap after the thread has died? Suppose you have a GUI and you want to launch a long-running computation without blocking the user interface. You don't know how long it will take, so you want the user to be able to cancel it if he gets bored.

If the code is in Python, you can use sys.settrace to handle this. If the code is in an extension module that a user has control over, having a cancel_thread() function that is made available to Python, and having your C code check the value of a single variable every few seconds could do the same thing (even checking the value in a tight loop shouldn't slow computations down significantly, branch prediction should be able to make it a more or less zero-cost operation). Yes, it can be tedious, but at least the programmer can actually control cleanup in a reasonable manner.

Option 3, farm the long running operation out to another process and use the OS-provided facilities to abort and cleanup if the user changes their mind. It's the only way to be sure the aborted operation doesn't leave the main process in a dodgy state. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

On 12:06 am, greg.ewing@canterbury.ac.nz wrote:

glyph@divmod.com wrote:

...

Can you suggest any use-cases for thread termination which will *not* result in a completely broken and unpredictable heap after the thread has died?

Suppose you have a GUI and you want to launch a long-running computation without blocking the user interface. You don't know how long it will take, so you want the user to be able to cancel it if he gets bored.

That's a perfectly reasonable use-case which doesn't require this feature at all ;).

Interaction with the rest of the program is extremely limited -- some data is passed in, it churns away, and some data is returned. It doesn't matter what happens to its internal state if it gets interrupted, as it's all going to be thrown away.

If that's true, then the state-sharing features of threads aren't required, which is the right way to design concurrent software anyway.

In that situation, it doesn't seem unreasonable to me to want to be able to just kill the thread. I don't see how it could do any more harm than using KeyboardInterrupt to kill a program, because that's all it is -- a subprogram running inside your main program.

The key distinction between threads and processes is the sharing of internal program state.

How would you handle this situation?

Spawn a process, deliver the result via an event. If you're allergic to event-driven programming, then you can spawn a process *in* a thread, and block in the thread on reading from the process's output, then kill the *process* and have that terminate the output, which terminates the read(). This is a lot like having a queue that you can put a "stop" object into, except the "file" interface provided by OSes is kind of crude. Still no need to kill the thread. At the end of the day though, you're writing a GUI in this use-case and so you typically *must* be cognizant of event-driven issues anyway. Many GUIs (even in the thread-happy world of Windows) aren't thread-safe except for a few specific data-exchange methods, which behave more or less like a queue. One of the 35 different existing ways in which one can spawn a process from Python, I hope, will be sufficient for this case :).