Do not install a file event to send data to rewrite child when parent stop sending diff to child in aof rewrite.

[huangzhw]

Do not install a file event to send data to rewrite child when parent
stop sending diff to child in aof rewrite.

In aof rewrite, when parent stop sending data to child, if there is
new rewrite data, aofChildWriteDiffData write event will be installed.
Then this event is issued and deletes the file event without do anyting.
This will happen over and over again until aof rewrite finish.

[oranagra]

WOW... that's bad.. a busy loop though the kernel eating 100% CPU.
i suppose it was like that since forever.. @huangzhw how did you notice it?

i wonder if we should maybe improve the tests to detect it?
i.e. similar to what i did in replication.tcl (compute_cpu_usage) to measure stime.
although unlike that diskless replication code, which is quite complicated, this one is quite simple, and i don't imagine we'll ever have a regression here, so maybe instead we should try to think of some generic mechanism that can detect these.
@yossigo do you have an idea?

[huangzhw]

@oranagra I read the code to find it.
But why a busy loop though the kernel eating 100% CPU?
This event is just installed once in an event loop. Then the event handler is executed, the event is removed. Just some useless event but not so severe. If there are no other commands written to aof, this event will not be installed.

[yossigo]

@oranagra The only thing I can think of is extend ae to track and report event creation/deletion, theoretically we could then use this info to find unexpectedly large number of operations on given fds in a given time. Practically I doubt if this effort would be very effective - I'm not in favor of it.

[oranagra]

@huangzhw you're right, it is not as severe as i thought... it just reminded me similar cases we had in the past that could stay in a loop due to epoll being level triggered, getting an event, exiting without doing nothing and then getting it again.

in this case, for each time we wake up due to a socket event and get some write command, we'll wake up just one additional time to do nothing. and each of these is paired with two additional epoll_ctl calls, so in total 3 excessive system calls per event.