Re: [Jack-Devel] jack and signals

Stéphane Letz <[hidden]> writes:

>>>  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.

The signal issue is present in jack1dbus as well. Back when I proposed
the dbus.patch for jack1 and it got refused, there was absolutely no
sense to change the jack1 jackd from sigwait to a real main loop. Even
these days some people don't understand why jackdbus needs a main loop
and thus is not really compatible with jackd, from the POV of user that
tends to look in the process monitor for a process with a name that
starts with "jack".

> If this API is not usable in dbus context, then either 1) you just
> don't use is at all..

I had impression that this is not really an option because the threads
that jack creates will get wrong signal setup.

> 2) this signal handling API has to be
> redesigned to be used in different context.

I never got the information about the reasoning behind design of the
signal setup in jack1 (IIRC in jack2 it is almost the same, copied
From jack1).

> 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?

I think 2) is better but I dont know how to do it. The bad news here is
that I never got motivation to investigate how to fix the issue. Mainly
because it is not that important compared to other issues that have to
be fixed.

-- 
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

1306542921.11043_0.ltw:2,a <87fwnz1x3w.fsf at arnaudov dot name>