Re: Sending an interrupt to the frontend?
- To: mathgroup at smc.vnet.net
- Subject: [mg127265] Re: Sending an interrupt to the frontend?
- From: "W. Craig Carter" <ccarter at MIT.EDU>
- Date: Thu, 12 Jul 2012 04:57:25 -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> <jtj648$5oo$1@smc.vnet.net> <20120711222332.250866850@smc.vnet.net>
Here is an example where killing the kernel doesn't release the frontend. At least for me, the frontend freezes and has to be killed with no opportunity to save. Don't try this unless you have saved your notebooks!!! rarray = RandomReal[{0,1}], {1024,1024}]; Dynamic[ArrayPlot[rarray]] (*the next step is a mistake, which is the point*) rarray = rarray. RandomReal[{0,1}], {1024,1023}]; W Craig Carter Sent from a portable device On Jul 11, 2012, at 18:23, Roland Franzius <roland.franzius at uos.de> wrote: > Am 11.07.2012 08:23, schrieb James Stein: >> 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" (i= f >> it is). Furthermore, the FrontEnd ought to be able to accept interrupts a= t >> 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 mu= st >> 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 Macinto= sh >>> "Force Quit" Mathematica, which is always irritating because of the lost= >>> work and time. >>> >>> With years of software experience, I understand why efficient computatio= nal >>> loops cannot be monitoring a flag or looking for an interrupt; neverthel= ess >>> 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 vi= a >>> 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 t= o >>>> 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 i= f >>>> a method to force the frontend to make an operating system query with a= >>>> user-specified time interval might be possible? > > > With 32bit-Windows seems to be the standard problem with signed > adresses constraint but not properly controlled up to 2 GB. > > With 4 GB memory and windows 64bit problems have gone. No problem > shutting down the lost kernel and saving the notebook in Version 8 > except in photoshopping. The GPU programming unit is probably not yet > ready to handle 12 MP jpegs. > > -- > > Roland Franzius >
- 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>
- Re: Sending an interrupt to the frontend?
- From: Roland Franzius <roland.franzius@uos.de>
- Sending an interrupt to the frontend?