On Nov 5, 2013, at 3:30 PM, Mikael mikael.rcv@gmail.com wrote:
What is the context here:
That all the GVM:s share one and the same heap so objects are inter-accessible between GVM:s, but, while the set of globals in existence is shared between GVM:s too, each GVM has a unique variable slot for each global?
So then, this context is what is calling for this new dependency abstraction?
Then to understand you further, please correct my following attempt at filling out some blanks:
Will each module be required to be initialized once per GVM (so that the module's globals in the GVM will refer properly to the module's procedures etc. on the heap) with the exception of modules containing bootstrap code (such as, launching the REPL), and therefore the dependency information will also contain for each module an instruction about if it is intended to be initialized in one or every GVM?
When you create a new GVM, will its global variables slots be empty or a copy of those of the "parent" GVM?
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.
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.
Please reformulate your questions with this new information.
Marc