[MPlayer-dev-eng] threaded cache

[Reimar Döffinger]

On Sun, Nov 27, 2011 at 12:23:09PM -0800, Scott W. Larson wrote:
> On Sun, 2011-11-27 at 20:52 +0100, Reimar Döffinger wrote:
> > On 27 Nov 2011, at 20:16, "Scott W. Larson" <scowl at wballphotos.com> wrote:
> > > On Sun, 2011-11-27 at 17:41 +0100, Reimar Döffinger wrote:
> > >> If you set the clock from 2100 to 2011 somewhen in-between the point
> > >> where you calculate the timeout and when you call pthread_cond_timedwait
> > >> it will wake up in 2100.
> > > 
> > > Does this problem only happen when someone changes the clock?
> > 
> > Yes. Adjustments by NTP or similar have of course the same effect if they cannot/are not done via temporary clock speed changes. No idea if you could come up with something crazy like an overflow in the time struct that would cause it too, but that's probably too far fetched to care about.
> 
> That's a relief. Changing the clock on our customers' systems will have
> far worse consequences than threads not timing out. Jobs won't be
> scheduled correctly. Parts won't be ordered. Accounting will probably
> not balance at the end of the month. Nightmare!
> 
> A lot of real-word business applications demand a monotonous clock.
> That's why on our customers' systems changing the clock manually is as
> forbidden as opening up the computer while the power is on.

Yes, a lot of systems are coded like that (sometimes with good reason,
sometimes not) which is why Linux introduced a method to make minor
clock adjustments by speeding it up/slowing it down to avoid any skips
that might cause issues.
On desktop systems the most frequent issue is actually suspend/resume,
which does not (or should not) cause issues in this case.
I guess on Windows the automatic summer/winter time adjustment is also
relevant.
Still, I've tried to make sure that most code in MPlayer should handle
it fine enough, and I don't like adding this kind of issue when the
benefit isn't all that convincing.
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...