Re: Sending an interrupt to the frontend?
- To: mathgroup at smc.vnet.net
- Subject: [mg127250] Re: Sending an interrupt to the frontend?
- From: James Stein <mathgroup at stein.org>
- Date: Wed, 11 Jul 2012 02:20:23 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: mathgroup-newout@smc.vnet.net
- Delivered-to: mathgroup-newsend@smc.vnet.net
- References: <20120710044050.C28C26835@smc.vnet.net> <20120710071807.037B567DE@smc.vnet.net>
Thinking further on this problem, it occurs to me that "Mathematica" comprises (at least) two processes: Mathematica and MathKernel. How does the Mathematica process respond if the MathKernel process is killed by an outside agency (such as a human using Mac's 'Terminal' as superuser)? I would hope that the FrontEnd would survive gracefully. If it is busy "formatting contents", it should eventually finish "formatting output" (if it is). Furthermore, the FrontEnd ought to be able to accept interrupts at least once every time it sends output to the active Notebook. So the question is: Why is this a hard problem? Wolfram employs lots of people who know lots more about this that me and most others, so there must be a reason for such bad behavior. Inquiring minds wish to know. On Tue, Jul 10, 2012 at 12:18 AM, James Stein <mathgroup at stein.org> wrote: > > 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 > > >
- References:
- Sending an interrupt to the frontend?
- From: W Craig Carter <ccarter@MIT.EDU>
- Re: Sending an interrupt to the frontend?
- From: James Stein <mathgroup@stein.org>
- Sending an interrupt to the frontend?