Re: [Jack-Devel] jack and signals

>> 
>> I think we should distinguish several things, in JACK2:
>> 
>> 1) what happens on server side : the code for signal management is
>> located in two functions jackctl_setup_signals and
>> jackctl_wait_signals (part of the so called "control API")
>> 
>> 2) on server side, the desire to precisely control the signal setup,
>> depending of the kind of process that is going to use the
>> "libjackserver" library (up to now: jackd or jackdbus)
>> 
>> 3) what happens on client (libjack) side: right now the SIGPIPE signal
>> is filtered to avoid JACK clients receive a SIGPIPE when trying to
>> access a died server (see JackLibGlobals constructor in
>> JackLibGlobals.h)
>> 
>> 4) an additional somewhat separated issue is the use of non
>> appropriate API (like "sigprocmask" instead of "pthread_sigmask")
>> 
>> We should probably try to refine 1) and 2) to see if
>> jackctl_setup_signals and jackctl_wait_signals have to be redesigned
>> to be more flexible. What are the precise constraints for jackdbus?
>> Nedko can you refine?
> 
> jackdbus needs to have a loop. jackd has no loop, it calls
> jackctl_wait_signals(signals). AFAICS jackctl_wait_signals() cannot be
> used for jackdbus because it will block the D-Bus loop.
> 
> Maybe dbus loop can be implemented in a separate thread but I'd like to
> avoid this, if possible.


To remember: jackctl_setup_signals/ jackctl_wait_signals was designed as a "restructuration" of jack1 initial signal code handling: the code was just separated as 2 functions. 

If this API is not usable in dbus context, then either 1) you just don't use is at all.. or 2) this signal handling API has to be redesigned to be used in different context. 

I still don't have a clear view of what is the correct approach: do you think 2) will make some sense? if yes, do you have any proposal to change the API?

Thanks.

Stéphane 

1306156453.13043_0.ltw:2,a <27DCA9B1-6030-4856-8FB2-E3950C36220A at grame dot fr>