Re: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R, system performance down!

On Sun, Feb 12, 2006 at 08:41:25PM -0500, Lee Revell wrote:

> On Mon, 2006-02-13 at 02:44 +0100, fons adriaensen wrote:
>
> > The real solution is to put the UI and RT parts in separate processes.
> > It's a bit more work, but not so much if you want to have a clean
> > interface between the two anyway.
> >
>
> What IPC mechanism would you recommend? I like the idea of using
> process shared mutex/CV objects backed by an mmap'ed tmpfs file. Not
> sure if this works with LinuxThreads though.
 
Depends a bit on the amount of data you need to exchange between the
two, and on the frequency of the interaction.

For low volume, you could use a pipe, and shared memory otherwise.
I'm currently working on two apps that use POSIX shared memory
for this. The UI part creates it, and forks and execs the RT part,
giving the shared memory filename as an argument. Any required
prefix such as sudo or rt_limits -r remains hidden (it's a
configuration item for the UI part of course).

For synchronisation a POSIX sema in shared memory is quite
fast. Alternatives are a named one or again a pipe. Didn't
yet test condition variables in shared memory. If those work
that would make it rather easy to make e.g. my clthreads lib's
ITC functions work tranparently across process boundaries.

AFAIK, putting synchronisation objects in shared memory will
not work with LinuxThreads. But how long will they still be
used ? Sooner or later new apps will require a 2.6 kernel,
and the initial problems with NPTL are well in the past
now.

-- 
FA