[vdr] Re: Kernel-Patch to make VDR undisturbable

[Andreas Schultz <aschultz@cs.uni-magdeburg.de>]

On Friday 05 April 2002 14:54, Matthias Lötzke wrote:
> Andreas Schultz (aschultz@cs.uni-magdeburg.de) schrieb:
> > I don't think patching the kernel is the right way to go.
>
> Do you see a possibility in userspace to make sure that VDR runs
> undisturbed? I do not. IMHO a kernel modification is unavoidable.

yep, SCHED_FIFO/SCHED_RR ;-)

> > Besides, you should
> > be able to achive the same thing by using real time scheduling priorities
> > and policy. SCHED_FIFO or SCHED_RR should do the same thing without the
> > kernel patch.
>
> No. Scheduling VDR with realtime priority can cause deadlocks. I did tests
> and whole machine stopped. A hardware reset was needed after.

I'm not surprised, from 'man sched_setscheduler':

       As  a  non-blocking  end-less  loop in a process scheduled
       under SCHED_FIFO or SCHED_RR will block all processes with
       lower priority forever, a software developer should always
       keep available on the console a shell  scheduled  under  a
       higher  static  priority than the tested application. This

There are quite some non-blocking end-less loops in vdr. As a starter one can 
try to replace/enhance all usleep() with sched_yield(). However, the better 
solution would to remove all busy type loops and replace the with some sane 
synchronisation.

The worst example of this is in dvbapi.c, cReplayBuffer::Input():

  while (Busy() && (blockInput || NextFile())) {
        if (blockInput) {
           if (blockInput > 1)
              blockInput = 1;
           continue;
           }

now, if blockInput is true, this will degrate into a tight non-blocking loop, 
no wonder vdr blocks the whole system under real time scheduling.

A patch to fix up the syncing in the ringbuffers, you can have a look at:
http://www.cs.uni-magdeburg.de/~aschultz/dvd/vdr-1.0.0pre3-sync.diff.bz2,
but i'm sure there are plenty of other places left.

Andreas