Re: Callbacks from modules

[Tom Tromey <tom@tromey.com>]

>>>>> "Philipp" == Philipp Stephani <p.stephani2@gmail.com> writes:

Philipp> The first is that such a facility would change the execution
Philipp> model of Emacs in a quite fundamental way.

I think instead that there is no fundamental change here.  The callback
scenario is no different from anything else in Emacs.

The things to disallow are calling into Emacs from a different thread,
or callbacks from signal handlers.  This is easily done -- the former is
done already and the latter can be done simply by fiat: "don't do that".

Philipp> Right now all user-defined code inside the Emacs process gets
Philipp> run through a path under the control of Emacs, either as a
Philipp> response to an input event, or a timer, or a process filter
Philipp> etc.

In my proposal in the relevant issue, this would not change.

Now, it should change a little.  It would be good to add fd-watching
capabilities to the module API; and it would be good to add some kind of
"do this later" API as well.  But even these aren't very different.

Philipp> The second issue is how such a facility should be made
Philipp> available. Currently all communication between modules and
Philipp> Emacs happens through modules, and there is no facility how
Philipp> modules can request creation of an environment. However, it
Philipp> makes little sense to discuss this issue until the first one is
Philipp> resolved.

I already proposed a solution for this as well: when a module requests a
runtime, keep it around.  Then let a module function request an
environment from the runtime at any time, and provide a way to tear down
such an environment.  Then a callback could get a new environment when
needed.

Tom