The value returned by reading from a timerfd is not an overrun
count in the same sense as for posix timers, it's an expiry counter.
Reflect that in the name.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Using posix timers "timer_tracker" as base class for timerfd was flawed.
Posix timers are not inherited by child processes and don't survive
execve. The method used by posix timers didn't allow to share timers
between processes. The timers were still per-process timers and worked
entirely separate from each other. Reading from these timers via
different descriptors was only synchronized within the same process.
This does not reflect the timerfd semantics in Linux: The per-file
timers can be dup'ed and survive fork and execve. They are still just
descriptors pointing to the same timer object originally created by
timerfd_create. Synchronization is performed between all descriptor
instances of the same timer, system-wide.
Thus, reimplement timerfd using a timer instance in shared memory,
a kernel timer, and a handful of sync objects.
Every process maintains a per-process timerfd struct on the cygheap
maintaining a per-process thread. Every process sharing the same
timerfd will run this thread checking the state of the timer, similar
to the posix timer thread, just working on the shared objects and
synchronizing its job with each other thread.
Drop the timerfd implementation in the posix timer code and move the
public API to fhandler_timerfd.c. Keep the ttstart timer_tracker
anchor out of "NO_COPY" since the fixup_after_fork code should run to
avoid memory leakage.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Corinna Vinschen