[MPlayer-dev-eng] threaded cache

[Dan Oscarsson]

sön 2011-11-27 klockan 21:39 +0100 skrev Reimar Döffinger:

> I still think there should be some better solution to this, or does
> everyone just accept that pthreads + timeouts = non-portable, fragile,
> ....?
> Unfortunately that is nothing I know much about, the closest I have
> in real experience is that the L4 microkernel supports both relative
> and absolute timeouts for that reason...

>From what I have seen most set clocks to use CLOCK_MONOTONIC if you want
to be sure it works even when clock jumps. Though it would seldom matter
for mplayer as there are enough other things that can make playing
uneven. For example timing_sleep in mplayer.c may make wrong sleep time
if clock jumps.

Where do you read that pthread_cond_timedwait is full of race
conditions? In my patch is is just there to be able to singla the thread
to continue before sleep times out. Even if it sleeps a little to long
it should not matter more then other delays in the system. I have timed
mplayer for frame displaying and seen that sometimes the Linux scheduler
delays the mplayer process (probably to handle i/o or other things)
outside sleeps making all timing in mplayer fail.

The code will work with just the usleep code, but will then not start
processing a control request as quickly as now. And you could remove the
timed wait and use queues of commands instead but then you need to move
input into a thread instead of polling is as is done today.

   Dan