If a timer is updated (re-added) with a different time period
(specified in the .data field of the kevent), the new time period has
no effect; the timer will not expire until the original time has
elapsed. This seems to violate the documented behavior as the
kqueue(2) man page says (in part) "Re-adding an existing event will
modify the parameters of the original event, and not result in a
duplicate entry." This modification, adapted from a patch submitted by
@cem to bug 214987, fixes the kqueue system to allow updating a timer
entry.
In his comments about the patch @cem noted that it "is probably
racy". I have not yet determined whether that is actually a problem.
There is a quirk of this change that I wonder about. Calling kevent()
with the EV_ADD flag on an existing timer and specifying a new
(different) timer length will effectively re-start the timer from the
point in time of the kevent() call. However, if the timer is re-added
with the same length as the original EV_ADD, the timer is unchanged
and continues running until the original calculated expiration. For
example, if the timer was originally added at time 0 with a length of
1000 and was re-added with a length of 999 at time 995, the timer
would be re-set and expire at time 1994. However, if it were re-added
with the original length of 1000, the timer would not be re-set and
would expire at time 1000. Therefore, as currently implemented, this
patch doesn't quite give the same effect as if the timer were first
deleted and the re-added with the new timer length. It seems to me
that this is rather counter-intuitive behavior. Would it be better to
have a re-add of an unexpired timer always re-set the expiration to
(current time + length of timer)?
PR: 214987