[LAD] New proposal for the jackd/jackdbus mess
letz at grame.fr
Wed May 20 12:06:17 UTC 2009
Le 20 mai 09 à 13:55, Krzysztof Foltman a écrit :
> Stéphane Letz wrote:
>> Not really, the existing IPC server/client scheme just need to be
>> extended with new "calls".
> Then, if you're keeping the "fork and exec" method of starting the
> server, will it in any way be guaranteed than all control clients will
> have the same functionality as the client which initially started
> Otherwise, starting a single client will prevent any control
> started later from being able to do its job.
In what way?
> In non-DBUS JACK the
> application that started jackd had a monopoly on access to its
Not clear for me.
> Also, what if the application that did fork and exec crashes?
Same behaviour as now, the server detects crashed client and stops if
started in "temporary" (-T mode)
or continue to run if started non temporary.
> What if
> the server crashes?
As usual, client can detect that using the "shutdown" callback.
> What if both crash, but other control applications
> are still running?
> I think that in any correct solution, the fact that
> an application has started jackd shouldn't give it any more (or less)
> influence on jackd than any other client in the system - otherwise
> it is
> a race condition. The hypothetical new version of qjackctl should have
> the same feature set no matter if it was started before or after, say,
> Can the same IPC protocol you plan to use for the control protocol be
> reused for the out-of-band MIDI SysEx data? (we've been talking about
> that before, and it's really out of scope of control protocol
> discussion, but it might be useful at some point).
No idea right now. I think we should focus on the global design.
More information about the Linux-audio-dev