On Sat, 10 Jun 2000, John Lazzaro wrote:
> Lots of dropouts are happening, so the user wants to cntrl-C, but he
> can't because nothing ever blocks!
[...]
> For both cases, it seems wise to have code smart enough to detect
> when a write hasn't blocked for a long time, and sneak in a forced
> SCHED_OTHER pass at an opportune time ...
Sounds all too familiar to me. SCHED_FIFO really is a dangerous feature to
play with. And especially when your app is controlled by outside
sources (users, other programs) and/or you have many state changes (processing
-> stop -> configuration -> startup -> ... etc). In these cases you have
to be really careful. It's a shame if there isn't any POSIX conformant way
to solve this problem.
In my apps, the best approach has been to safe-guard all state change
points. For instance, when processing is stopped, I make sure that all
SCHED_OTHER processes have plenty of time to react to the new situation. This
has proven to work quite well, but unfortunately not in situations where
CPU-load is causing the problems. I know there are many alternatives (watch-dog
thread, possibly sigtimedwait), but I'd like have something more standard.
Anyway, if someone comes up with the perfect solution, I'd really like to
hear it. :)
--
Kai Vehmanen <[EMAIL PROTECTED]> ---------------- CS, University of Turku .
. audio software for linux .. http://www.eca.cx .
. armchair-tunes mp3/wav/ra . http://www.wakkanet.fi/sculpscape .
