<div><div> </div><div>Re Marc:</div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div class="im">Multiple global environments are useful for creating separate instances of the Gambit VM in the same OS process which do not share the global variables.  This might be useful in a "shared nothing" multithreading model (like Erlang/Termite).  But for a shared-memory model (like Multilisp) a shared global environment would be appropriate, with the advantage of no overhead for accessing global variables.</div>

</blockquote><div> </div><div>That there will be no overhead on global variable access with 'SMP Gambit' is great!</div></div><div> </div><div><div> Re Raffael:</div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">

<div class="im">Would those separate VMs run in separate OS threads (which the OS could then schedule on separate cores even if they are running in the same process)?</div></blockquote><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">

<div class="im">IOW, for many of us, the advantage of multiple VM instances is that they could take advantage of multiple cores. Having multiple VM instances in the same OS process seems, to some of us at least, somewhat less useful.</div>

</blockquote><div> </div></div><div>Mm - currently when SMP shared-memory-model support is not available as per Marc's PhD thesis, it's great that we now have the option of compiling Gambit to support concurrent use of multiple OS threads, and even greater when this SMP support will be there :-D</div>

<div> </div><div>Kind regards, Mikael</div><div> </div>