From alsa-devel-owner@alsa.jcu.cz  Tue Jan 12 12:59:52 1999
Received: from ife.ee.ethz.ch (ife-fast.ee.ethz.ch [129.132.24.193])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id MAA14140
	for <alsa-devel@alsa.jcu.cz>; Tue, 12 Jan 1999 12:57:19 +0100
Received: from ife.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.24.203])
	by ife.ee.ethz.ch (8.8.5/8.8.5) with ESMTP id MAA26156;
	Tue, 12 Jan 1999 12:57:18 +0100 (MET)
Message-ID: <369B389D.FB567AB5@ife.ee.ethz.ch>
Date: Tue, 12 Jan 1999 12:57:17 +0100
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
MIME-Version: 1.0
To: alsa-devel@alsa.jcu.cz
CC: Stephen Thornton <Stephen.John.Thornton@ericsson.no>
Subject: Re: Linux scheduler issues.
References: <199901092046.PAA25489@renoir.op.net>
		<19990111101124Z2631-2281+1905@nic.funet.fi> <9901111407.AA10574@tele2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Stephen Thornton wrote:

> But remember, besides your nice little audio app. there are quite a
> lot of system processes that can suddenly preempt at awkward moments,
> and no way of knowing what they might do to your delicate audio
> timings. Short of re-writing the Scheduler and kernel, there is not a

Can you be more specific?

Suppose your process did sched_setscheduler(SCHED_FIFO, somethinghigh) and
mlockall(MCL_CURRENT|MCL_FUTURE).

Now how can any other process preempt you? Can you show me
the call sequence?

The only things that can preempt you (IMHO) are:

Interrupts:  IDE is notorious about doing too much
  work in the interrupt handlers and disabling ints for
  a long time, but otherwise the handlers are usually small
Bottom Halves: Im pathological cases may consume almost
  all CPU time (such as a high bandwidth network router
  on a 386), but otherwise short too.

Short of that (which can be avoided by not doing something silly), I
can't see how your app can be preempted seriously, especially not
by any other process.

What you can do however is preempt yourself, such as by
blocking syscalls, by calling syscalls that require memory
when there's none available, or by calling syscalls that
require semaphores another process holds.

I can't quite see how anything of the above is a problem
for audio apps that basically only burn CPU cycles and
do IO to the soundcard (given a reasonable sound driver).

Tom

