Re: [linux-audio-dev] jack_callback <-> rest of the world

On Wed, 2005-11-02 at 11:48 +0100, Florian Schmidt wrote:
> On Wed, 2 Nov 2005 11:05:34 +0100
> Stéphane Letz <letz@email-addr-hidden> wrote:
>
> > In Jackdmp we have tested 2 system for inter-process synchronization:
> > fifo (the way it was done in regular jackd) and POSIX named semaphore
> > (which are built on top of futex on recent system version)
> >
> > In both cases, each already running client get access to the
> > synchronization primitive (fifo or POSIX named sema) defined by a new
> > coming client. The synchronization primitive is "opened" once when a
> > new client appears and is "closed" when the client quits. The
> > synchronization primitive that has to be signaled then depends of the
> > graph topology.
> >
> > > But ISTR that OSX only has named shared futexes (i.e. accessed
> > > via a file descriptor), and then of course the problem remains.
> >
> > On OSX, on can use Mach semaphore (internal and non portable...)
> > POSIX named semaphore or fifo.
> >
> > Stephane
>
> What results did you get? Did the semaphore perform better/worse than
> the fifo? What about pthread condition variables with pshared flag set?
> I read somewhere it should be implemented by now (at least on 2.6
> systems).

I've tested process shared mutexes/CVs with NPTL 2.3.5 on Linux 2.6 and
it works perfectly - I'm able to synchronize multiple processes via a
mutex/CV residing in shared memory, backed by an mmap'ed file in /tmp.
The performance is indistinguishable from the single multithreaded
process case.

Is there any good reason JACK could not use this rather than FIFOs?
Lack of robustness?

Lee
Received on Wed Dec 7 04:15:05 2005