[MPlayer-dev-eng] threaded cache

[Reimar Döffinger]

On Mon, Nov 28, 2011 at 10:07:14AM +0100, Dan Oscarsson wrote:
> 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.

Does it work on BSD? Does it work with MinGW pthreads? Solaris?

> 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.

Sleeping until the year 2100 as in my example is not just "playing
uneven". I admit it hardly happens for normal cases, but it is still
brittle code.

> Where do you read that pthread_cond_timedwait is full of race
> conditions?

To do a relative sleep the suggested method is to add the offset to
the current time to get an absolute value.
pthreads then subtracts the current time from that value again.
This leaves a race conditions for when the time changes in-between
these.
Worse, it will also silently fall back from clock_gettime to
gettimeofday (both when either the kernel does not support it or
when glibc was compiled against older kernel headers) - no idea
if and how that is possible to detect.

> 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.

What other delays can be anything from milliseconds to years?

> 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.

Huh? A thread for a thread for the main thread? I am not sure what you
are thinking of.
The much better solution I can see (for POSIX systems, I don't think it
will be easy to get to work for Windows) would be using pipes and select
(which at least does offer a proper relative timeout).
You wouldn't even have to send the actual data through the pipe, just
misusing it as a wakeup signal should work.
I still don't particularly like it, it sounds like it would be not the
cleanest code.