<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/6 Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Gambit's threading model will be two tiered.  There's the concept of Gambit virtual machine (VM) and the concept of "processor".  These conceptually correspond to the classical operating system abstractions of process and thread, but these abstractions are not a 1-to-1 mapping to the OS abstractions.  In fact, each processor is an OS thread and a VM corresponds to a self contained address space.<br>


<br>
So a VM has an independent set of global variables and a heap (where Scheme objects are allocated).  A VM cannot access the global variables and the heap of another VM, at least not directly.  Within a VM, there are multiple processors (OS threads) running.  These processors can share objects and access the same global environment.  So a VM is the natural choice for implementing Termite's concept of "process", whereas the shared-memory concurrency provided by processors is ideal for implementing futures.<br>

</blockquote><div><br></div><div class="gmail_extra">Aha - this abstraction makes enormous sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Please reformulate your questions with this new information.<br></blockquote><div><br></div><div>Am all clear now, thank you.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<span class=""><font color="#888888">Marc<br>
</font></span></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">To your request for feedback regarding whether to <span style="font-family:arial,sans-serif;font-size:13px">change the linker data structures to record module dependencies,</span></div>

<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">I would propose you instead only implement a fundamental core functionality for</span><span style="font-family:arial,sans-serif;font-size:13px"> the user to declare whether a linked-in module should also be executed on start.</span></div>

<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">This way, you leave dependency handling logics all to the user to perform himself programmatically, just as it is now - preliminarily I believe this would be for the win in the bigger picture, for instance considering the </span><span style="font-family:arial,sans-serif;font-size:13px">level of</span><span style="font-family:arial,sans-serif;font-size:13px"> </span><span style="font-family:arial,sans-serif;font-size:13px">flexibility and control it gives.</span></div>

<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra">

<span style="font-family:arial,sans-serif;font-size:13px">This is my preliminary feedback.</span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra">

<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">Find my reasoning behind this below, and also four followup questions, highlighted.</span></div>

<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra"><br></div><div class="gmail_extra">Best regards,</div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">Mikael</span><br>

</div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px"> - </span></div><div class="gmail_extra">

<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"><br></div><div class="gmail_extra"><b>Context</b></div><div class="gmail_extra">

So, the levels are</div></div><div class="gmail_extra"><br>Gambit global level contains one or more Gambit VM:s.</div><div class="gmail_extra">A VM is/represents/has a Scheme environment (global variables environment, address space, etc).</div>

<div class="gmail_extra">Each Gambit VM contains one or more Gambit processors.</div><div class="gmail_extra">A Gambit processor is running at max one CPU core at a time, and generally Gambit processor creation implies an OS thread creation.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><span style="background-color:rgb(217,234,211)">And, each Gambit processor is running one or more green threads right?</span></div><div class="gmail_extra"><span style="background-color:rgb(217,234,211)">And, there is some way that the user can assign and reassign executing processor within the VM, for a green thread?</span></div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Ok context understood.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><b>Problem</b></div>

<div class="gmail_extra">So the conversation topic now is, that now that C linking/loading means a concurrent loading to the C level of all Gambit VM:s at the same time, then how should injection and execution of the loaded Scheme code be done into the VM:s, now that the user wants differentiated behavior between VM:s.<br>

</div><div class="gmail_extra"><br></div><div class="gmail_extra">So problems that come with this are that for C code [modules] loaded, on the one hand</div><div class="gmail_extra"> * you need a way to define what code [modules] is actually executed in the primordial VM&processor as code not intended to be executed there on load can be linked in too, and, on the other hand</div>

<div class="gmail_extra"> * you need a way to specify what code [modules] should be executed in other VM:s.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This is the same problem as Unix and other OS:es face on boot: where to start execution, what's the first process and how to commence operations from there. The difference is just cosmetic in that a Unix system has the modules (the "init" program etc. and library files) in a filesystem while Gambit has them also on the heap already (the prelinked modules that this conversation are about).</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Indeed, in Unix each module (executable & library) has a dependencies definition, and the OS loader is tasked to loads those deps.</div><div class="gmail_extra">

<br></div><div class="gmail_extra"><b>Possible solution (A): Gambit bundles dependency loading logic. |preload-module| + hook</b></div><div class="gmail_extra">Gambit can reuse this as |<span style="font-family:arial,sans-serif;font-size:13px">preload-module| (as you suggested) and due to its higher level of abstraction have such dep definitions not just per module but per lambda in a module (as you suggested).</span></div>

<div class="gmail_extra"><br></div><div class="gmail_extra">For this to be fully satisfactory, (as you said) the user needs to be able to inject modules both in form of interpreted and compiled code on runtime.</div><div class="gmail_extra">

<br></div><div class="gmail_extra">This probably also means there needs to be some runtime hook for a module system to perform the actual dependency loading, at the most basic level meaning resolving what already-linked-in module is actually meant by a particular module name specified to |<span style="font-family:arial,sans-serif;font-size:13px">preload-module|.</span></div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><b>Possible solution (B): Gambit does not bundle dependency loading logic. (declare (not execute-on-load)) / (load module #!optional (execute-on-load? #t)) , |create-vm!|, |inject-module!|</b></div>

<div class="gmail_extra">So, the alternative would be something like vyzo suggested above: That</div><div class="gmail_extra"><br></div><div class="gmail_extra">Gambit not contains recursive dependency loading logic per the suggestion above, but just</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"> 1) a way to specify which linked-in modules should be actually executed by the primordial VM&processor on start</div><div class="gmail_extra">     (all linked-in modules, executed on start or not, can be commanded to be executed by the interface described below)</div>

<div class="gmail_extra">      , and then</div><div class="gmail_extra"><br></div><div class="gmail_extra"> 2) a programmatic interface to handle process creation and module execution, including operations to</div><div class="gmail_extra">

<br></div><div class="gmail_extra">      * create a Gambit VM including specifying the module it should be started (injected and executed on its start) with - |create-vm!| , and</div><div class="gmail_extra"><br></div><div class="gmail_extra">

      * a command to inject & execute a given module into the current VM - |inject-module!|</div><div class="gmail_extra"><br></div><div class="gmail_extra">..and like in the suggestion above, modules here can either be interpreted or compiled, and linked in or loaded on runtime.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">1. could be achieved with an argument to |load| and for when |load| happens on executable start due to C linking, using a declare form, like, (declare (not execute-on-load)) .</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Both (A) and (B) require some way to enumerate modules, be it as a symbol name or using a first-class object representation.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">In this moment given my current understanding, I'd vote rather for (B).</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">(B) is more basic and fundamental and programmatic.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Also, (A) can be implemented in terms of (B) anyhow, I would believe, adequately well?</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="background-color:rgb(217,234,211)">Please share</span></div><div class="gmail_extra"><span style="background-color:rgb(217,234,211)"><br>

</span></div><div class="gmail_extra"><span style="background-color:rgb(217,234,211)"> * if you see any options beyond these two, and</span></div><div class="gmail_extra"><span style="background-color:rgb(217,234,211)"><br>

</span></div><div class="gmail_extra"><span style="background-color:rgb(217,234,211)"> * if you see any reason for Gambit to do (A) that I may not have understood right now.</span></div><div class="gmail_extra"><br></div>

</div>