[Openmcl-devel] Handling error in a callback

[Gary Byers]

On Tue, 30 Mar 2004 taube at uiuc.edu wrote:

> >and there's no good way to exit the (nested) break loop.
> >You should clearly be able to exit the break loop in this
> situation;
> >it's less clear to me where you should exit -to-.  (One
> reasonable
> >choice might be to simply unwind out of as much lisp code as
> we can
> >and kill the thread.)
>
> is this something that you will be adding to cvs? would it be
> possible to establish some unwind-protect in the callback such
> that it could have the option of "resetting" after an error
> before unwinding further to the top-level? but really, pretty
> much any solution other than the current situation of not
> being able to recover would be a help!


The backtrace difficulty that I mentioned is due to a fencepost
in CCL::%PTR-IN-AREA-P: the second comparison should use #'>, not
#'>=

(defun %ptr-in-area-p (ptr area)
  (declare (fixnum ptr area))           ; lie, maybe
  (and (<= (the fixnum (%fixnum-ref area ppc32::area.low)) ptr)
       (> (the fixnum (%fixnum-ref area ppc32::area.high)) ptr)))

(In this context, if a stack pointer's pointing at the exclusive
upper bound of an "area", it's not in the area anymore and we've
found the bottom of the stack.)

As to where a callback should return to when it exits an unexpected
break loop: I don't think that the lisp should be deciding that for
you, but I think that it could help you to enforce certain conventions.

One convention is to return a negative integer from a foreign function
that would ordinarily return a non-negative integer.  You could do this
manually:

(defcallback int-returning-function (:int)
  (block :exit
    (restart-case
        (maybe-error-when-computing-non-negative-int)
      (abort () (return-from :exit -1))
      (ccl:abort-break () (return-from :exit -1)))))

but if you had to do it often it might be nice if a macro did most of
the hard work.

Similarly, you could establish a handler on entry to the callback and
have it decide what to do if an error was signaled during its execution.
(Again, this might be a common enough idiom that some syntactic support
might be helpful.)

Whether and how a given callback can gracefully return an error indication
to the caller (or otherwise respond reasonably in that situation) depends
on its contract.

If there's no handler in effect and are no restarts for the break loop
to exit to, I don't think that there's much of an alternative to killing
the thread



> thanks,
> Rick Taube
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>