[Date Index] [Thread Index] [Author Index]
Re: Sending an interrupt to the frontend?
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" (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? 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