Re: [Jackit-devel] Re: Real-Time Preemption,-RT-2.6.10-rc2-mm3-V0.7.31-19

[Florian Schmidt]

On 02 Dec 2004 10:26:55 -0600
"Jack O'Quin" <joq@xxxxxx> wrote:

> 
> > On Thu, 2 Dec 2004 07:46:20 -0800
> > Andrew Burgess <aab@xxxxxxxxxxx> wrote:
> > > On further thought, I suppose libjack could install a SIGUSR2 handler and
> > > have that call abort for all the rt client threads. Still no client mods
> > > needed, only an RT-aware libjack.
> 
> Florian Schmidt <mista.tapas@xxxxxxx> writes:
> > right. Or instead of aborting jackd might print a debug output (like
> > "client foo violated RT constraints"). 
> 
> Libjack cannot assume the client has no SIGUSR2 handler of its own.

i see..

> It would be wonderful to have a reliable mechanism for debugging them.

I suppose instead of catching the signal the user might just monitor the
syslog. I'm not sure there's printk's triggered by thisalready , but i'm
sure if not, ingo might add them. So a trivial patch for jackd would
probably look like this:

--- libjack/client.c.orig       2004-12-02 17:55:04.000000000 +0100
+++ libjack/client.c    2004-12-02 17:56:23.000000000 +0100
@@ -1238,6 +1238,9 @@
                        if (control->sync_cb)
                                jack_call_sync_client (client);
 
+                       // enable atomicity check for RP kernels
+                       gettimeofday(1,1);
+
                        if (control->process) {
                                if (control->process (control->nframes,
                                                      control->process_arg)
@@ -1247,7 +1250,10 @@
                        } else {
                                control->state = Finished;
                        }
-
+
+                       // disable atomicity check
+                       gettimeofday(0,1);
+
                        if (control->timebase_cb)
                                jack_call_timebase_master (client);
 
flo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/