Why doesn't Mathematica abort evaluation when I tell it to?
There are two processes running. The first process is the FrontEnd. The FrontEnd receives your keypresses and renders text and plots. The second process is the Kernel. The Kernel receives commands to perform calculations, stores the states of variables, and does pretty much all the calculating.
When you press Alt-., the FrontEnd immediately receives your abort command. It immediately passes it to the Kernel. In the Kernel, the abort command is queued until the Kernel actually checks its queue of things to do. If the Kernel is busily executing a calculation, it may only check the queue infrequently. There is a tradeoff here -- if the kernel frequently interrupts calculations to check the queue, the calculations take noticeably longer to run; if it checks infrequently, abort commands take a long time to have effect.
After the Kernel checks the queue, it will terminate the current calculation. This termination can also take a while. (If your calculation produces checkpointing output, it is easy to see that the checkpointing output stops.) It was much worse in earlier versions of Mathematica. For instance, I have had calculations that ran for a day, were aborted, then spent another day meticulously freeing memory for bazillions of temporary results, one at a time. (Kernel: "I'm done with these four bytes." OS: "OK." Kernel: "I'm done with these four bytes". OS: "OK." ...) (This was far more likely if the computation had intermediate expression swell sufficient to significantly spill into swap.)
When the cleanup is complete, the Kernel is ready to continue calculating.
In the context of your Question and comments to it, it is important to note that no process is terminated by an abort. If you really want to abort a calculation and you are willing to re-evaluate all the context you had before the computation, you can "Quit Kernel", which does result in killing the Kernel process. If the system is excessively busy (say swapping a working set that is about twice as large as memory), even this can take a long time because even the FrontEnd will become nonresponsive. (First I have to get the OS to reload the code for what to do when someone clicks on a menu item. ... Okay. Now I have to get the OS to reload the code for the callback for that particular menu item. ... Okay. Now I have to ...) It is interesting/frustrating to watch the FrontEnd have to swap in code to figure out how to draw the menus and deal with overlaps. My fingers still have Alt-k-q (menu:Kernel: Quit) in muscle memory as a way to minimize the amount of swap-in required to kill a kernel. (Note that this key sequence hasn't worked for several versions of Mathematica.)
The situation has already been explained by Eric Towers in more detail and clarity than I would have been capable of, but as far as a solution goes I think I have a slightly better one:
- How do I clear all user defined symbols?
This gives me a keyboard shortcut Ctrl+Q to kill the kernel, and it is now a reflex action if I realize that I just asked Mathematica to do something that is going to hang the system. Naturally you will lose all of the in-memory definitions, but with a well structured Notebook restoring them is usually much faster than dealing with a hung system.
This keyboard shortcut seems to act faster and more reliably than walking the menus by key command as Eric advised.
Recommended reading:
- Aborting evaluation when the memory exceeds a certain limit
If you ever develop a library for LibraryLink, be sure to include calls to AbortQ to support aborting lengthy computations.
Code that runs for a long time should call AbortQ to see if the user has aborted the computation.
Otherwise, your library will be one of the causes of long-ignored aborts.