[MPlayer-users] Re: [Patch] Re: Problem with -slave and A-V sync

[Dirk Meyer]

Reimar Döffinger wrote:
> Hello,
> On Sun, Dec 03, 2006 at 01:13:42PM +0100, Dirk Meyer wrote:
>> I found the problem, but I can't really explain it. The problem is
>> that usec_sleep is called with 0 as sleeping interval some times. This
>> shouldn't be a problem, but it causes my problems. nanosleep seems to
>> sleep at least a very short time. The following patch resolves that
>> problem by catching the usec_delay == 0 before calling nanosleep.
>> Sounds stupid, but this fixes my problems.
>
> sleep always acts as a yield, i.e. it will cause a thread switch.

I know. Every system call will cause the scheduler to run in the
kernel.

> Though if this causes performance problems you either have
> 1) something else running that soaks up all the cpu time freed

No. I have a second core just doing nothing. There are other
processes, but my system is idle most of the time, at least the second
core.

> 2) a really bad OS where a yield is expensive even when only one process
> is runnable

Linux 2.6.18 doesn't sound like a bad OS to me. The funny part is that
the bug is only there when using -slave and the usleep stuff is in the
functions that reads the keys from normal input. 

> Anyway, fixed in SVN r21468.

Thanks

> Btw. finding the cause is easy with gdb if instead of "return 0;" you do
> "*(char *)NULL = 0;"...

I don't understand. Without testing it, this should cause mplayer to
segfault and the gdb kicks in. But what can I do now? I can't go
deeper into the kernel after that point. What am I supposted to do in
gdb? 


Greetings,

Dischi

-- 
There can't be a crisis today, my schedule is already full.