[Openmcl-devel] Restart strangeness

[Will]

Gary Byers <gb at clozure.com> writes:

> On Tue, 22 Jun 2004, Will wrote:
>
>> 1 > :r
>> 0. Return to break level 1.
>> 1. #<RESTART ABORT-BREAK #x4B8856>
>> 2. Retry applying FOO to NIL.
>> 3. Apply specified function to NIL this time.
>> 4. Specify a function to use as the definition of FOO.
>> 5. Return to toplevel.
>> 6. #<RESTART ABORT-BREAK #x4B8CCE>
>> 7. #<RESTART ABORT-BREAK #x4B8E06>
>> 8. #<RESTART ABORT #x4B8E2E>
>> 1 > (:c 8)
>>
>> At this point OpenMCL just hangs until interrupted with ^C
>>
>
> That ABORT restart causes the listener thread to exit.  It isn't generally
> very useful to invoke this (IIRC, it's basically just there so that calling
> ABORT will do something other than complain that "there's no active restart
> named ABORT.")
>
> The little menu of restarts that :R presents is generated from the
> value returned by COMPUTE-RESTARTS (which, by definition, includes
> things that are shadowed by restarts of the same name that have been
> established more recently.)  Restart 0 in your test case is also named
> ABORT, and it would/should be invoked if you call (ABORT) in the break
> loop.  (This would be clearer if the :R menu showed the name of the
> restart as well as the description, and the catch-all restarts (7 and
> 8) should either not be displayed in the menu or given descriptions
> that say "you probably don't want to invoke this from a break loop;
> doing so will kill the initial listener and leave you in an
> environment where the initial thread is looping around wondering why
> things have gotten so quiet all of a sudden ...".

Thanks for the explanation!  The same sort of thing occurs in SLIME's
restart menu for restarts 4 and 5:

Restarts:
  0: [CONTINUE] Retry applying FOO to NIL.
  1: [USE-VALUE] Apply specified function to NIL this time.
  2: [STORE-VALUE] Specify a function to use as the definition of FOO.
  3: [ABORT] Abort handling SLIME request.
  4: [ABORT-BREAK] #<RESTART ABORT-BREAK #x1692E06>
  5: [ABORT] #<RESTART ABORT #x1692E2E>

After your explanation I watched the results of :proc and these seem
to have the same effect of killing or resetting the SLIME REPL
threads.

Thanks,
Will