23 Jan
2008
23 Jan
'08
10:54 p.m.
Bob Ham <rah(a)bash.sh> writes:
On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov
wrote:
static void *
jack_watchdog_thread (void *arg)
{
jack_engine_t *engine = (jack_engine_t *) arg;
engine->watchdog_check = 0;
while (1) {
usleep (1000 * JACKD_WATCHDOG_TIMEOUT);
if (!engine->freewheeling && engine->watchdog_check == 0) {
jack_error ("jackd watchdog: timeout - killing jackd");
/* Kill the current client (guilt by association). */
if (engine->current_client) {
kill (engine->current_client->
control->pid, SIGKILL);
}
/* kill our process group, try to get a dump */
kill (-getpgrp(), SIGABRT);
/*NOTREACHED*/
exit (1);
}
engine->watchdog_check = 0;
}
}
Bob Ham <rah(a)bash.sh> writes:
A good example. What does the watchdog do, exactly? It isn't a
frontend. I doesn't try to work around jackd's crashing. It just
ensures that if something bad does happen, the computer as a whole isn't
brought down. This is massively different from what you're proposing.
To try and work around a crash in jackd and present a system to the user
where crashes make no difference is to invite more problems. If you
can't get jackd to stay up, what makes you think you can get your new
system to stay up? More generally, LASH isn't a frontend for
JACK.
What about the jack watchdog? What does get killed by it? It seems that what you want is Patchage++.
Unfortunately, LASH isn't
that and I think you're likely to run into problems if you try and turn
it into that.
JACK *will* be improved (at least its dbus-interface) to fix this issue.
Just out of curiousity, how?
I'm not completely sure yet, but even the jack code posted above
shows that jack server engine knows what is the pid of each client.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
* lash should be able to manage not lashified apps at
least to extent
of launching them and connecting their ports.
The problem here is that there's no way to know which ports belong to
the app.