From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 79FAB7EFCD; Fri, 31 Oct 2014 16:03:54 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of whitequark@whitequark.org) identity=pra; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of whitequark@whitequark.org designates 176.58.103.125 as permitted sender) identity=mailfrom; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.whitequark.org) identity=helo; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="postmaster@mail.whitequark.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ank6AMCjU1SwOmd9/2dsb2JhbABchnBQhi6wLQaBRJYqgyACgSsBAQEBAX2EAwEBBCMPAQVBEAQHGAICJgICLCsGGxOIKrVjlHkBAQgCAR+BLYUKhByFL4EOB4J3gVQBBItrkz6DSo1EhAmCAB4WgUc6gnoBAQE X-IPAS-Result: Ank6AMCjU1SwOmd9/2dsb2JhbABchnBQhi6wLQaBRJYqgyACgSsBAQEBAX2EAwEBBCMPAQVBEAQHGAICJgICLCsGGxOIKrVjlHkBAQgCAR+BLYUKhByFL4EOB4J3gVQBBItrkz6DSo1EhAmCAB4WgUc6gnoBAQE X-IronPort-AV: E=Sophos;i="5.07,295,1413237600"; d="scan'208";a="103988795" Received: from fehu.whitequark.org (HELO mail.whitequark.org) ([176.58.103.125]) by mail2-smtp-roc.national.inria.fr with ESMTP; 31 Oct 2014 16:03:53 +0100 Received: by mail.whitequark.org (Postfix, from userid 33) id 67E0110BEDB; Fri, 31 Oct 2014 15:03:52 +0000 (UTC) To: =?UTF-8?Q?Christoph_H=C3=B6ger?= X-PHP-Originating-Script: 1000:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 31 Oct 2014 18:03:52 +0300 From: Peter Zotov Cc: caml users , caml-list-request@inria.fr In-Reply-To: <54539FD9.1050709@tu-berlin.de> References: <54539FD9.1050709@tu-berlin.de> Message-ID: X-Sender: whitequark@whitequark.org User-Agent: Roundcube Webmail/1.0.1 Subject: Re: [Caml-list] is it possible to embed an OCaml interpreter into an OCaml Module? 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