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