MathGroup Archive 2012

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

Search the Archive

Re: Sending an interrupt to the frontend?

  • To: mathgroup at
  • Subject: [mg127260] Re: Sending an interrupt to the frontend?
  • From: Roland Franzius <roland.franzius at>
  • Date: Wed, 11 Jul 2012 18:23:32 -0400 (EDT)
  • Delivered-to:
  • Delivered-to:
  • Delivered-to:
  • References: <> <> <jtj648$5oo$>

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

  • Prev by Date: Re: How to write code for Plotting Polar Coordinates in r
  • Next by Date: Algorithm Analysis Course: Should I use Mathematica for projects?
  • Previous by thread: Re: Sending an interrupt to the frontend?
  • Next by thread: Re: Sending an interrupt to the frontend?