Stefan Monnier <
address@hidden> schrieb am So., 13. Sep. 2015 um 15:14 Uhr:
> The case where a module calls an emacs function that ends up calling
> signal/error.
OK, what are you worried about w.r.t that case?
It's not possible to skip frames in module code using longjmp, so module_funcall needs to set up handlers before calling Ffuncall.
> I don't know enough about how signaling and unwind-protect work. It's
> just black stack magic for me right now :)
Fsignal works using longjmp. unwind-protect (and dynamic let-bindings)
works by adding things onto a stack which Fsignal will run just prior to
calling longjmp.
> I think we just need to implement funcall (from the module API) like this:
> global error = 0
> module_funcall(fun, args):
> // wrap (protect?) this with the right code
> // - to keep the control
> // - set ret to nil and error to 1 in case of error
> ret = Ffuncall(fun, args)
> return ret
> The error is accessible via error_get(), error_clear() and
> error_check() in the module API. error_get() is currently redundant
> with error_check() unless we decide to return detailed errors.
I don't understand what kind of error handling you have in mind.
How/why/when would we use things like error_get, error_clear, etc...?
Because setjmp/longjmp and therefore Fthrow/Fsignal don't work, you need to design a different error handling API that doesn't rely on non-local jumps. There are three options: return values, output parameters, thread-local state. All three have their pros and cons; Daniel opted for the third. The error_... functions are needed to access that thread-local state.
> I didn't think about the case where a module calls Fthrow but my guess
> is it will just work. I have to test thoroughly what I have already
> anyway, I'll see if it works.
Fthrow uses the same technique as Fsignal, and I think your intuition is
right: it should just work (for both).
No, it can't. See Daniel's initial posting where he designed the module API.