[gambit-list] Gambit linking
alvaro.castro.castilla at gmail.com
Wed Nov 6 03:03:45 EST 2013
It would be like a module system without the namespaces. I think that this
is a very nice step, because it's an important part of the functionality of
Blackhole or Schemespheres, but with the new features that you can
implement at a lower level.
I'd actually like that this goes one step further an build a minimal module
system (even if just select which variables to export per module). Such a
simple module system (export / depends-on) would be very helpful for
developing bigger applications with Gambit.
On Tue, Nov 5, 2013 at 6:10 PM, Marc Feeley <feeley at iro.umontreal.ca> wrote:
> Currently a Gambit executable program is a list of modules, with the
> "main" program as the last module. During the setup phase (function
> ___setup) these modules are initialized sequentially (as though they were
> "load"ed in turn). For example, the Gambit interpreter, gsi, consists of
> these modules ("_kernel" "_system" "_num" "_std" "_eval" "_io" "_nonstd"
> "_thread" "_repl" "_gsilib" "_gsi"). The module "_gsi" contains the code
> which starts the REPL.
> This is fine in the context of a single Gambit VM instance per OS process.
> However, for the upcoming multithreaded Gambit, I want to support multiple
> VM instances per OS process, so the current linking model is not ideal. If
> the current linking model isn't changed, each VM instance will have to run
> the same program (requiring all VMs to initialize all the modules of the
> program), and the programmer will have to create custom logic in the "main"
> program to select the appropriate VM behaviour. This is clumsy.
> So I'm considering changing the linker data structures to record module
> dependencies. Something like "before initializing module A, it is
> necessary to initialize modules B, C, and D". An executable program would
> thus be a set of modules with dependencies, and the name of the main
> module. The setup phase would do a depth first traversal of the dependency
> graph starting at the main module.
> This would enable a few interesting features:
> 1) Allow the instantiation of a VM with a "main" module different from the
> other VMs, e.g. (start-new-vm "other-main").
> 2) Lazy initialization of modules (only the modules actually relevant to
> the main program need to be initialized).
> 3) Multiple modules could be bundled this way in a single executable
> program. The "load" procedure could be changed to lookup modules in the
> bundled set before going out to the file system to dynamically load a .o1
> file. This would simplify the installation of multi-module applications
> and give better startup performance.
> Note that for this to work, it will be necessary for the compiler to
> record module dependencies with each module and to output these
> dependencies in the linker data structures. A new special form, such as
> (depends-on <module>), will have to be added so that the programmer can
> express initialization dependencies in the source code. For consistency,
> the interpreter will also have to support this form.
> Before going forward with this change, I would like to have some feedback.
> Do you see problems with this or suggestions?
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list