|
|
Re: Sending an interrupt to the frontend?
Posted:
Jul 10, 2012 3:18 AM
|
|
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@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
>
|
|
