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

[Phil]

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

Between Hamilton's suggestion and your follow-up suggestion, I think we 
have a winner.  Your notion that a memory error is serious enough to 
warrant program failure makes sense but a way to allow for more graceful 
handling putting the responsibility on the developer to figure out how 
to deal with.  It also addresses the Slime hang which is essentially the 
same problem.

Is this something that would be of general enough value to add to a 
future release of OpenMCL? (if so, going a step further, would a global 
variable which contained a list of conditions (assuming there are 
others) which should not result in the kernel debugger be a more general 
solution to the issue?)

Thanks,
Phil