Re: [Caml-list] is it possible to embed an OCaml interpreter into an OCaml Module?

[Peter Zotov <whitequark@whitequark.org>]

On 2014-10-31 17:42, Christoph Höger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear all,
> 
> I already asked this on stackoverflow and was pointed to
> compiler-libs.toplevel - indeed this API seems to be sufficient to run
> an OCaml interpreter from inside an OCaml program (as that seems to be
> what utop does).
> 
> But ist it also possible in some way to embed that interpreter safely
> in an OCaml Module (so I can reuse it e.g. from within utop)?
> Currently, it seems that there is exactly one dedicated toplevel for
> every running bytecode interpreter and when running utop, it is
> already in use.
> 
> So what I would need would be the ability to execute a phrase from
> within a call of execute_phrase. I already clonded the toploop module
> and for tehe time being I am fine with that. What I need is a way to
> 
> a) safe the already set ('outer') toplevel value bindings
> b) restore the nested value bindings
> c) execute the compiled bytecode
> d) restore the 'outer' value bindings
> 
> is there someone who can point me to a solution?

There is nothing special about the toplevel or the OCaml interpreter.
Indeed, you can run a chunk of OCaml code at any time using
the caml_callback C call--this is exactly what the runtime would
invoke at startup, or what the toplevel would do to run a freshly
compiled phrase.

However, the OCaml runtime has quite some global data:
a cursory look brings up GC, backtrace machinery, polymorphic
comparison (!), debugger, dynlink (and its symbol tables),
exceptions, finalizers, and a few more things. Depending on your
desired level of isolation, it might be very hard to provide
a clean environment.

Incidentally, can someone explain how the runtime manages to be
multithreaded while it has so much global data? Please don't
tell me the answer is "every thread copies it back and forth
on context switch".

-- 
Peter Zotov