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.cawrote:
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...., 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 makeAnd then
cd multiple-vm-example makethen
telnet localhost 12345to 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