[Openmcl-devel] Is this an OpenMCL 'problem'?

[Gary Byers]

On Fri, 7 Apr 2006, Hamilton Link wrote:

>
> On Apr 7, 2006, at 2:30 PM, Phil wrote:
>
>> Gary Byers wrote:
>>
>>>
>>> I don't think that either of these approaches is entirely optimal.  I
>>> think that I'd ultimately favor a mixture of the two: dropping into
>>> the kernel debugger first, but providing an option to attempt to
>>> recover
>>> by treating the exception as a lisp error.
>>>
>>
>> I appreciate the detail on the options and rationale and it makes sense
>> how and why it's being handled the way it is.  From a development
>> standpoint, it would be nice if Slime handled the situation better (OT
>> for this list so I'll take it over to slime).  From a deployment
>> standpoint, does this approach preclude a graceful exit of an app?
>> (i.e.
>> at least log the error and present the user with an error dialog before
>> exiting)
>>
>
> GB always knows infinitely more about this than I do, so I'll let him
> suggest the _how_, but it seems like a sensible _what_ might be that
> even if memory got a proper thrashing, for situations where you
> survived as far as the kernel debugger invocation that function could
> be replaced in advance (by rebuilding the kernel, I'm thinking) with a
> routine that makes a couple of simple Carbon calls to pop up a dialog
> explaining what was going on, and give you a choice of dumping
> everything (invoke all the kernel dumping stuff) or quitting and
> sending a nastygram to the distributor.  I would be astonished if a
> C-level hack wasn't required.
>

It wouldn't be too hard to have a kernel-accessible global variable -
something like *ALWAYS-TREAT-MEMORY-FAULTS-AS-LISP-ERRORS* - and the only
kernel hacks that'd be required are very similar to all of the stuff
that already exists (a lot of lisp error situations cause other types
of exceptions, and the kernel code that handles those exceptions
often does so by calling out to lisp.

In a GUI OSX application, the kernel debugger isn't (usually) going
to be there; the process's standard input is /dev/null, and standard 
output and error go to a logging device (so a message describing
the "unhandled exception" or other problem will be logged, the
debugger will try to read a command from its standard input, get
an EOF, and the application will exit.

*ALWAYS-TREAT-MEMORY-FAULTS-AS-LISP-ERRORS* (if/when it exists)
should probably be the default for a GUI application, simply because
trying and failing to run the kernel debugger isn't a reasonable
option.  If a GUI application gets a "MEMORY-FAULT" lisp condition,
then it can decide how to handle it (unless the application somehow
knows why the fault happened and what its impact is, shutting down
quickly is probably not a bad idea, but it can presumably chose
from several different means of notifying the user/logging info.)

For development in a TTY environment, I still think that entering
the kernel debugger first is probably/mostly the right thing: even
though the debugging facilities are limited, there's some advantage
to being stopped at the point of the exception and of having other
threads suspended while you're in the debugger.  Like I said yesterday,
the biggest problem is that there's no easy way of saying "I understand
why the fault happened, get me to a break loop and I can fix the
problem ...".