Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2012

[Date Index] [Thread Index] [Author Index]

Search the Archive

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
>>>
>>>
>>
>
>



  • Prev by Date: Help with Reduce and ForAll
  • Next by Date: FindCurvePath has a problem
  • Previous by thread: Re: Sending an interrupt to the frontend?
  • Next by thread: Re: Sending an interrupt to the frontend?