Re: Dynamic loading progress

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]

Aurélien Aptel <aurelien.aptel+emacs@gmail.com> schrieb am So., 13. Sep.
2015 um 01:11 Uhr:

> On Sat, Sep 12, 2015 at 10:42 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> 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.

[-- Attachment #2: Type: text/html, Size: 4026 bytes --]