Hi Jules and other Multicore /real time gurus out there !
I am working on a project which will require optimised plugin hosting. I want to be able to maximise use of all the CPU cores available to the full.
Under my scheme, any plugin hosted will run in a single cpu / process , but i plan to launch several instances of my hosting code -with each host instance having its own memory to house a pool of plugin instances. The idea is that requests for new plugin instances get farmed out in around robin fashion to balance load across the CPU cores.
The plan is that these multiple “hosts” will receive MIDI and return audio blocks back to a central “controler” which will then coordinate the flow of MIDI/audio to/from the main app and the “plugin host instances”.
There seems to be two ways i could do this:
A) have a single JUCE app, and use seperate pre-emptive threads ( or maybe just co-operative threads if this still allows the OS to farm seperate co-operative threads to different CPUcores ) for each host instance. Each pre-emptive thread would have its own memory to hold a collection of plugin instances. Each host thread would communicate back to the main app thread via shared memory. Host threads would be woken from sleep each time a new audio block is required.
B) Implement each host instance as a SEPERATE JUCE console app running in the background all communicating back to the main app via shared memory plus IPC/ signals etc.
The seperate app ( process ) approach B) is one that comes to me highly advocated highly by me fellow developers working in my other language/IDE - REALStudio/REALbasic . But this is partly because the framework it uses is not thread safe and it uses its own co-operative theading model.
Everyone states that B is just much safer and easier to debug.
I should add that there is no complex “plugin chaining” needed - and this simplifies the restrictions on how I handle my plugin instances and how they sit across processes/threads.
An thoughts JUCE gurus ?