Re: Sending an interrupt to the frontend?
- To: mathgroup at smc.vnet.net
- Subject: [mg127363] Re: Sending an interrupt to the frontend?
- From: James Stein <mathgroup at stein.org>
- Date: Fri, 20 Jul 2012 03:50:12 -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: <jtj5ro$5ml$1@smc.vnet.net> <jttuv8$gtl$1@smc.vnet.net> <20120719075040.3BB426861@smc.vnet.net>
Dear Michael, You asked of Ralph; but I wish to answer as well (although my opinions of Mathematica are much higher than Ralph's). Most users sometimes make mistakes. (I make many.) Sometimes an evaluation which ought to complete in a short time takes a long time and may be on its way to infinity. Finite beings will wish to abort such evaluations. Were Mathematica a single process, occasional difficulty in interrupting a calculation would be understandable, perhaps forgivable, perhaps unpreventable. Whatever tight (efficient) loops may exist in the program could be substantially slowed if they had to "listen for interrupts"; possible solutions are difficult because different hardwares and different operating systems differ substantially. But as I understand it, Mathematica is commonly implemented as two processes, a FrontEnd (the interactive Notebook) and a BackEnd (the kernel). Assume the kernel is running away, computing an Ackermann function perhaps. I imagine two cases: (1) the kernel is busy computing and sending no output. (2) the kernel is flooding the FrontEnd with more output than it can format and handle in real time. Case 1 seems unproblematic to me. The FrontEnd is idle, it should be easy to respond to human input and interrupt the kernel if possible, otherwise abort it. In either case, the FrontEnd should survive and Notebooks can be saved. Case 2 is the problem. Both the FrontEnd and the BackEnd are busy busy busy. If the FrontEnd is merely receiving a gazillion short lines to output, it seems it could handle interrupts after every line. So likely the problem is when the FrontEnd receives an output so large in size that it goes into a very long loop formatting that output. I would hope that somewhere in that loop would be a place to look for interrupts. This would slow formatting (not by much, I would hope), but in normal cases this would not matter much (10.1 seconds instead of 10 seconds) and in the problematic case, does user care if formatting takes 12 years and a month instead of 12 years? So that's my naive view, and why I think the problem ought be solvable, unless in the face of memory issues. In olden times, when the stack crashed into the heap, all bets were off. I'm not aware of how more modern memory management works, but would hope that the FrontEnd, while checking for an interrupt could also check for how much free memory remains and, if it looks dubious, could do something intelligent (alert user and wait?) before disaster strikes. Of course, I am a computer dinosaur so these views may look very silly to current experts. Best regards to all, -- James On Thu, Jul 19, 2012 at 12:50 AM, Michael Weyrauch <michael.weyrauch at gmx.de> wrote: > Ralph, > > I really would like to understand your critical remarks somewhat > better. > > It is clear that one can easily and quickly run the frontend irresponsive. > However, in most cases I know, this is actually due to bad programming > (from Mathematica's point of view) rather than an instable product. > > One typical reason is that a command returns symbolic results where the > programmer actually expected only numerical stuff, and quickly things get completely out of hand. But how should Mathematica know that all this was not intended? > > It is the tremendous flexibility and the many possibilities which > sometims get into the way, and as a consequence the frontend can not > handle the output from the kernel any more. > > I really do not understand where you expect Wolfram to get "its act > together". My experience tells me: A good Mathematica program may run > for days without any instability. But my stupitidy and/or lasy > programming can run it against > the wall within seconds. Mathematica as such is definitely not unstable. > (of course, sometimes there are bugs as with any other major (and minor) > software). > > Michael > > > Am 15.07.2012 10:28, schrieb Ralph Dratman: >> David, >> >> "Troublesome" puts the matter rather tactfully. >> >> Bluntly, there is no excuse for a major product to display such a >> level of instability in 2012. >> >> Since I personally like Mathematica so much, and because I use it >> constantly, I find the crashes to be both an embarrassment and a >> disappointment. >> >> I can only hope Wolfram Research will soon get its act together on >> this critically important issue. >> >> Ralph >> >> >> On Sat, Jul 14, 2012 at 1:28 AM, David Bailey <dave at removedbailey.co.uk> wrote: >>> On 12/07/2012 10:00, Yves Klett wrote: >>>> In earlier incarnations, the kernel would show up as a separate entry in >>>> the taskbar (on Win XP, that was), which made it very convenient to >>>> kill. I kind of miss that behaviour (when things go wrong repeatedly). >>> >>> I wrote a C program that executes the command >>> >>> c:\windows\System32\taskkill.exe /im MathKernel.exe /t /f >>> >>> This runs in the background all the time, and responds to a hot key! >>> >>> The fact that I took time to set this up, probably reflects just how >>> troublesome kernel hangs can be! >>> >>> Perhaps at the very least Mathematica could spawn a program of this type. >>> >>> David Bailey >>> http://www.dbaileyconsultancy.co.uk >>> >>> >> > >
- References:
- Re: Sending an interrupt to the frontend?
- From: Michael Weyrauch <michael.weyrauch@gmx.de>
- Re: Sending an interrupt to the frontend?