I am not sure if this is a/the race some users are seeing, or if it even can have any effect, but this will close it at a cost of one extra kevent(2) every 100ms timer tick.
I am not sure if this is a/the race some users are seeing, or if it
even can have any effect, but this will close it at a cost of one
extra kevent(2) every 100ms timer tick.

The (perceived) problem is that we have pending kqueue changes we
have not yet told the kernel about, then close a number of expired
FD's which might be instantly be recycled by the accept(2) over in
the other thread before we tell the kernel about the pending changes.

In that case, the kernel has no way of knowing that our changes
referred to the previous instance of the fd and not the new one.

The solution is to push the changes to the kernel before servicing
the timer.



git-svn-id: 7d4b18ab7d176792635d6a7a77dd8cbbea8e8daa@2401 d4fa192b-c00b-0410-8231-f00ffab90ce4

CartoDB/Varnish-Cache,CartoDB/Varnish-Cache,wikimedia/operations-debs-varnish,ssm/pkg-varnish,wikimedia/operations-debs-varnish,wikimedia/operations-debs-varnish,wikimedia/operations-debs-varnish,ssm/pkg-varnish,ssm/pkg-varnish,ssm/pkg-varnish,ssm/pkg-varnish,wikimedia/operations-debs-varnish,CartoDB/Varnish-Cache