[libdispatch-dev] Using libdispatch/GCD in a real-time context

[Stéphane Letz]

Hi,

We are interested to see if libdispatch/GCD could be used in a real-time context, more specifically in JACK audio server (http://jackaudio.org/). JACK audio server can connect a number of different applications to an audio device, as well as allowing them to share audio between themselves. Its clients can run in their own processes (ie. as normal applications), or can they can run within the JACK server (ie. as a "plugin"). JACK allows synchronous execution of all clients, and low latency operation. All JACK applications are connected in a graph and the server  (triggered by a CoreAudio audio callback) is responsible to "execute the graph" at each audio cycle, starting from the inputs and transferring "activation" from client to client until the outputs of the graph have been executed. 

On OSX JACK uses mach semaphores for inter-process communication. Each client start a thread and give it RT behavior (more precisely the thread is a "time-constraint" thread in OSX terminology and inherit the "period, computation, constraints" parameters of the server CoreAudio RT thread). On multi-cores machines, audio clients may themselves want to use additional helper threads, to speed up audio computation. This can be done using a pool of RT threads, but obviously doing like that does not scale well, when several applications do the same thing.

We looked at libdispatch/GCD as a possible alternative for this "explicitly managing RT threads" model. We were thinking in completely dropping the client RT thread and replace it by a "dispatch_source" to be triggered by the inter-process semaphore. Then use libdispatch again to replace the need for RT helper threads.

Right now there is no way to define a real-time queue in libdispatch, but would this kind of extension be theoreticaly possible? What would be the way to do that? Any comment on the overall idea?

Best Regards

Stéphane Letz