Commit 74df22be authored by Committed by Kristian HøgsbergBrowse files
test: Add test showing blocking problem when updating timers
I've noticed a blocking problem in Wayland's event-loop code when updating timer event sources. The problem occurs if you update the timer at a point after is has expired, but before it has been dispatched, i.e. from an event callback that happens during the same epoll wakeup. When the timer is subsequently dispatched, wl_event_source_timer_dispatch blocks for the duration of the new timeout in its call to read() from the timer fd (which is the expected behaviour according to the man page for timerfd_settime). This isn't too uncommon a scenario - for example, a socket with an associated timeout timer. You'd typically want to update the timer when reading from the socket. This is how I noticed the issue, since I was setting a timeout of 1 minute, and saw my server blocking for this duration! The following patch adds a (currently failing) test case to Wayland's event-loop-test.c. It demonstrates the problem using two timers, which are set to expire at the same time. The first timer to receive its expiry callback updates the other timer with a much larger timeout, which then causes the test to block for this timeout before calling the second timer's callback. As for a fix, I'm not so sure (which is why I thought I'd post the failing test case first to show what I mean). I notice that it doesn't actually do anything with the value read from the timerfd socket, which gives the number of times the timer expired since the last read, or when the timer was last updated (which blocks if the timer hasn't yet expired). I believe this value should always read as 1 anyway, since we don't use periodic timers. A simple fix would be to use the TFD_NONBLOCK option when creating the timerfd, ensuring that the read call won't block. We'd then have to ignore the case when the read returns EAGAIN.
Showing with 74 additions and 0 deletions