Re: [Jack-Devel] jack and signals

Le 13 mai 2011 à 01:33, Nedko Arnaudov a écrit :

> Dan Muresan <[hidden]> writes:
> 
>> Hi,
>> 
>> I've just noticed that Jack does its own signal handling. Since
>> applications may well expect to interact with SIGINT and even SIGPIPE,
>> conflicts may arise. Is Jack's use of signals specified anywhere? What
>> signals can a client handle and from what threads, what signals can it
>> block, are existing handlers chained by Jack, etc?
>> 
>> I also noticed calls to non-multi-threaded signal functions (such as
>> signal(), sigprocmask ()) in the jack2 codebase -- mostly in examples,
>> but also in common/JackControlAPI.cpp. POSIX specifically states that
>> any use of these functions is unspecified in multi-threaded programs.
>> Since their threading-safe counterparts (pthread_sigmask(),
>> sigaction()) are used elsewhere in the codebase, their use could be
>> easily eliminated.
>> 
>> BTW, I'm in jack2 now. But such things should be specified for both
>> jack1 and jack2.
> 
> I'd be really happy if this gets cleared up. And even happier if
> jackdbus finally can catch SIGINT and SIGERM.
> 
> -- 
> Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>
> 

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?  3) should be possibly redesigned (is "chaining handlers" mandatory in this case?)  4) is probably easy (API adaptation).


Stéphane 

1305623638.6698_0.ltw:2,a <3216AB3D-9D7F-4C22-8203-284040B99797 at grame dot fr>