Subject: Re: [linux-audio-dev] sched_setscheduler question ...
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sat Jun 10 2000 - 01:34:30 EEST
On Fri, 09 Jun 2000, John Lazzaro wrote:
>
> This is basically a way for the application to let
> a "control-C" in the shell that creates it to terminate it
> once every few minutes, w/o having to go through the hassle
> of locating the X server, window manager, xterm, and shell
> and setting them all to SCHED_FIFO too.
One way is to make your login shell SCHED_FIFO
(which then starts up X11 which inherits SCHED_FIFO too ecc),
but that harms the purpose of SCHED_FIFO since other processes
could monopolize the CPU for too long time, making your realtime app suck.
As long your app does not enter an infinite loop , ctrl-C is not a problem,
since when you output audio using write() , you block regularly, thus giving the
chance to all other processes to run, and to intercept your ctrl-C.
The fun starts when you enter an infinite loop.
At this point you are screwed.
One way to avoid this would be to let your app start a 2nd thread which
runs with higher SCHED_FIFO priority than the main thread.
the "watchdog" should simply check the content of a variable,
check if the value = 1 , then set it to 0 and then sleep for a second or so.
if the variable is 0 then kill the main thread.
The main thread has to set the variable to 1 periodically (more often than
the avove 1sec sleep).
in the case that the main thread enters an infinite loop, the watchdog thread
will discover this, because on the next run it will find 0 instead of 1.
At this point kill the other thread.
This should produce "lock-up proof" code which even if your app is buggy,
either exits or segfaults , but does not freeze your box.
hope this helps.
PS: sorry for my ignorance what is the exact purpose/application field of
sfront ? let's say you have an MP4 file which describes an audio file.
You pipe it through sfront, get a C file , compile it, and then
running the C program you get the original audio file ?
Is that the purpose ? (correct me if I am wrong)
But that will not be suitable for realtime decoded streams like in the
case of an MP3 player.
Or course I am missing something obvious ... :-)
Benno.
>
> ---
>
> Thanks in advance,
>
> --john lazzaro
>
> -------------------------------------------------------------------------
> John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
> lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
> -------------------------------------------------------------------------
--
This archive was generated by hypermail 2b28 : Sat Jun 10 2000 - 01:13:26 EEST