Re: [LAD] Summercode 2008: LASH as a D-Bus service

Bob Ham <rah@email-addr-hidden> writes:

> On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov wrote:
>> Bob Ham <rah@email-addr-hidden> writes:
>>
>> > More generally, LASH isn't a frontend for JACK.
>>
>> What about the jack watchdog? What does get killed by it?
>
> 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?

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

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev