In article <4C1A5BA8.1080507@...>,
Daniel Weinreb <dlw@...> wrote:
> If you run SBCL with --disable-debugger, the documentation says:
> By default when SBCL encounters an error, it enters the builtin
> debugger, allowing interactive diagnosis and possible intercession.
> This option disables the debugger, causing errors to print a
> backtrace and exit with status 1 instead. When given, this option
> takes effect before loading of initialization files or processing
> |--eval| and |--load| options. See |sb-ext:disable-debugger| for
> details. See Debugger Entry
> However, when there is an unhandled error in a thread other
> than the initial thread, SBCL does not exit.
> Is this intentional?
> I notice that make-thread does not use handling-end-of-the-world,
> and if it did, then I think SBCL would exit in that case.
Unhandled errors in different thread than the main thread are
in general bad shape. It does not seem to be possible to use
the debugger interactively in that case, so you can't even
get a backtrace.
In Slime, the problem manifests itself, too, in that "B" in the
Slime debugger is useless on SBCL -- it's supposed to break into
the implementation's native debugger.
Iirc, ECL implement this case by suspending all running threads,
hijacking the main thread, and waiting for user input there.