| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
can schedule the background thread
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently our fast clock is implemented by a background thread which
wakes up every 10ms if callers continue to check it's time. If that
background thread get's descheduled for a long time for some reason,
this can cause the background threads time to drift substantially.
If we:
* force every read of date_t::now to update a new date_t::lastNow
* change the background thread so that it's responsibility is to wake up
and call Date_t::now() (if readers are still present)
* change the background thread clock source now() to return
date_t::lastNow
We'll get a world in which we have the same target granularity + thread
quiescence as before, but additionally ensure that even if the
background thread can't be scheduled, that lastNow() will still be
pushed loosely forward if there are callers of Date_t::now() elsewhere
in the system. This should ensure a tighter bound on the spread between
the precise and fast clock sources
|
|
|
|
|
|
| |
Remove leading comments that are just stating the filename.
Move any file-level comments below the copyright banner.
Remove leading blank lines.
|
| |
|
|
|
|
|
| |
This both makes the test run much faster and avoids spurious failures when
the system scheduler decides not to run a thread for over a second.
|
|
|
|
|
| |
If it goes through a full granularity of sleeping without being read from, it
will sleep with no timeout until the next attempt to read the clock.
|
| |
|
|
BackgroundThreadClockSource & FastClockSourceFactory
|