Marc,

Thank you for the example! This will definitely allow me to run multiple threads to separate UI from audio processing.

I will try to dig a bit deeper to understand how the VMs work. One of the things I need to do is invoking a function on a specific VM (to generate audio I need to register a C callback that is invoked on a thread that is not controlled my me). My plan is having a standard VM running the main program and have another "idle" VM that will only be invoked by the C callback function. This way I should avoid corruption of the main VM stack. This idle VM would receive the information it needs from an in process message queue or a socket. If I can find the way of invoking the function on the right VM, I think my problem would be solved.

Thank you!

Regards,

Francisco

On Sat, Apr 5, 2014 at 12:17 PM, Marc Feeley <feeley@iro.umontreal.ca> wrote:

On Apr 1, 2014, at 10:06 AM, Francisco <fjvallarino@gmail.com> wrote:

> I have not found the post you mention. Based on https://mercure.iro.umontreal.ca/pipermail/gambit-list/2014-February/007441.html, I understood it was a work in progress... If you remember the thread, it would be great.

Here is an example that uses the multiple VM support. I’ve tested it on OS X only, but it should be portable to other OSes.

You first have to build Gambit with

./configure --enable-multiple-vms
make

And then

cd multiple-vm-example
make

then

telnet localhost 12345

to connect to the VM that is created.

There are still issues with the multiple VM support, notably the VMs share a single console, which means there are race conditions if you try to read/write things to the console from different VMs. This is why the example code runs one of the VMs on a network connection (which is probably what you want to do anyway in practice).

Marc