[vdr] Re: Avoiding NPTL problems

["Dr. Werner Fink" <werner@suse.de>]

On Thu, Jun 10, 2004 at 10:47:02PM +0200, Clemens Kirchgatterer wrote:
> Ludwig Nussel <ludwig.nussel@gmx.de> wrote:
> 
> > With regard to removing the usleeps, that's necessary as far as I
> > can tell since the manpage of nanosleep (usleep is wrapper for
> > nanosleep) says
> > 
> > 'If the process is scheduled under a real-time policy like
> > SCHED_FIFO or SCHED_RR, then pauses of up to 2 ms will be performed
> > as busy waits with microsecond precision.'
> > 
> > According to this the scheduler would not switch to another thread
> > during the usleep which would explain why it causes hangs.
> > 
> > There are other usleeps in recorder.c and transfer.c and
> > coincidentally recording also has problems with NPTL.
> 
> if the reason for the usleep()s is to force or at least allow a context
> switch to happen, wouldn't it be much better to use sched_yield() ?

Hmmm ... with NPTL we should use

      pthread_yield();

to be POSIX conform.  The NPTL threads within _one_ process should
reschedule not the process its self.

         Werner
> 
> i would consider the (ab)use of usleep for this purpose a bug anyway.
> ;-)
> 
> see the man page for details.

Agree.  Nevertheless VDR needs something like an usleep on NPTL base
to force rescheduling even if the time slice of the current thread
isn't used.  This could be done by simply using a condition variable
and pthread_cond_timedwait() ... may be with the help of the class
cCondVar.

        Werner

-- 
AC3 loop through sound card http://bitstreamout.sourceforge.net/
Howto http://www.vdr-portal.de/board/thread.php?threadid=1958
------------------------------------------------------------------
 "Having a smoking section in a restaurant is like having
         a  peeing section in a swimming pool." -- Edward Burr