------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=972 Phil Pennock <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #392 is|0 |1 obsolete| | --- Comment #8 from Phil Pennock <[email protected]> 2010-09-06 07:34:37 --- Created an attachment (id=400) --> (http://bugs.exim.org/attachment.cgi?id=400) exim_wait_tick() paranoia redux (1) In comment 6, I wrote "which I'm entirely convinced by" -- there is a missing "not" word there, sorry. (2) I just spent too much time tracing through all the logic for the time flows; I've clarified some messages and adjusted the patch to include a bound on iteration count. At this point, I'm calling it done for the evening. That's not saying this is the right patch yet. What is the correct behaviour when a clock steps back? What if it's a 305-second step back (admin noticed drifting clock when a 5-minute-sync-requirement protocol broke)? Well, if the clock goes back early in the process and the signal is delivered at the correct time, things will work. If the signal is late, there will be a second 305-second sleep. If the clock goes back later in the process, we'll sleep for 3x[very small delta] and still not catch up, so give up. So this patch should account for any normal breakages caused by timed signal deliveries firing prematurely. But I haven't rearchitected anything to assume all kernels are broken and not inclined to do so tonight. Does anyone feel like submitting a better patch? If not, I'll probably submit this. Or perhaps a minor variation which adds non-debug logging, as Simon suggests. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
