Re: [Jack-Devel] jack and signals

On Sat, May 28, 2011 at 03:34:43AM +0300, Nedko Arnaudov wrote:
> 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".

but there seems to be some sense, to fix the control api now, for
jack-dbus. 
all that jackd cared about was that the threads it creates ignore all
signals. jack doesnt need signals. it just used SIGUSR1 to communicate
that the backend died, and shutdown is indicated.

this whole jackctl_setup_signals/ jackctl_wait_signals is completely
useless.
jackctl_server_start() needs to make sure, that the threads it creates
block all signals.
"backend died" just needs to be a callback. than any jackctl user can take
appropriate actions.

just clean up that api. 
we dont need signals in jack. 
(maybe we need to make sure that the main thread doesnt get SIGPIPE...
but its probably safer to just document, that SIGPIPE might be
generated and any jackctl user needs to either ignore them, or if it
needs them itself, needs to be prepared for spurious occurances.


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

yes. the stuff that jackctl_setup_signals() does, needs to be done inside 
jackctl_server_start() before it calls pthread_create() and then undone.

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



> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


-- 
torben Hohn

1306612962.6963_0.ltw:2,a <20110528200212.GA8601 at siel dot b>