[Date Index] [Thread Index] [Author Index]
Re: Sending an interrupt to the frontend?
I have experienced the same (or similar) problem. For me, it usually occurs unexpectedly, in which case it is likely that I have not recently saved the notebook(s) before the evaluation that goes awry. After pressing command-period and the menu item "Quit Kernel" repeatedly, to no effect, it seems there is no escape except the Macintosh "Force Quit" Mathematica, which is always irritating because of the lost work and time. With years of software experience, I understand why efficient computational loops cannot be monitoring a flag or looking for an interrupt; nevertheless it would be nice to have a mechanism to stop the kernel without stopping the FrontEnd. This would -- I think -- resolve an occasional situtation I experience where the Kernel is outputting information faster than the FrontEnd can format and display it -- so the FrontEnd seems too busy to accept an interrupt and the BackEnd (Kernel) seems unstoppable except via the FrontEnd. Am I understanding the situation? Perhaps not... On Mon, Jul 9, 2012 at 9:40 PM, W Craig Carter <ccarter at mit.edu> wrote: > > Hello Mathgroup, > > This is a question about frozen frontend behavior. > > In development stages, one of my frequent mistakes is to send the > frontend something that takes forever to dynamically update---at least > that is what I believe what is happening for most of the "freezing" > occurrences. For MacOs, this is often signaled by a "Formatting > Notebook Contents" window. > > I wonder if anyone has found a method to send the front end a message to > stop dynamically updating while in an unresponsive state? I've various > versions of kill -s signal (i.e., signal = INT) from a terminal in > MacOSx, but never with success. > > I suppose that having the front end query the operating system for > interrupt requests would create a lot of overhead. However, I wonder if > a method to force the frontend to make an operating system query with a > user-specified time interval might be possible? > > W Craig Carter >