Aurélien Aptel <
address@hidden> schrieb am So., 13. Sep. 2015 um 01:11 Uhr:
On Sat, Sep 12, 2015 at 10:42 PM, Stefan Monnier
<address@hidden> wrote:
> Can you give us more details about you mean by the above.
> Are you talking about how to handle things like calls to Fsignal, or to
> Fthrow, or how to provide access to unwind-protect and condition-case in
> to the module's?
The case where a module calls an emacs function that ends up calling
signal/error. I don't know enough about how signaling and
unwind-protect work. It's just black stack magic for me right now :)
They use longjmp, which doesn't work in modules. Your implementation needs to make sure that no longjmp ever escapes to module code, i.e. that none of the stackframes skipped by longjmp can lie inside a module. See what Daniel wrote above:
"When Emacs calls a module function, the current thread's pending-error
flag will be clear. When that module returns to Emacs, if the
thread's pending-error flag is set, Emacs signals the condition
corresponding to the current thread's error information.
When the module calls an Emacs routine that would ordinarily signal,
Emacs catches the signal at the stack frame just before control flow
would return to the module, sets the pending-error flag, and returns
to the module normally."
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
Here you probably need to call both internal_catch and internal_condition_case.
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.
What do you mean with 'detailed errors'? At a minimum users need access to the handler type (condition-case or catch), the catch tag, the error symbol, and the error data. Most likely the stacktrace should also be provided.
I didn't think about the case where a module calls Fthrow but my guess
is it will just work.
It uses a different handler type and therefore will probably not work out of the box unless you call internal_catch.
> Indeed it's not guaranteed at all. It's not even guaranteed that when you
> call the GC, all dead objects will be collected.
Ok. Finalizers are better than nothing I guess.
Why would you need finalizers at all? There are usually wrong and useless in languages with nondeterministic garbage collection.