On Feb 12, 2014, at 11:41 AM, Steve Allen wrote: > On Wed 2014-02-12T11:22:57 -0700, Rob Seaman hath writ: >>> On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote: >>>> Meanwhile, whatever discussions occur on this list should flow from >>>> documented case studies: >>>> >>>> >>>> http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf > >> In particular, Steve Allen's paper is the most complete exploration >> of the topic in question, and itself references a variety of resources >> well worth reviewing. > > For completeness, I recently encountered an earlier list of linux > kernel leap issues at > http://winningraceconditions.blogspot.com/2012_07_01_archive.html > I haven't checked to see how much overlap is in the lists.
"An obvious zeroth-order conclusion: There were/are disproportionately many disastrous race conditions in the leap second code simply because it's such an infrequently-executed codepath. Hence, there's a call for some extra form of verification apart from "run the code as it is" - whether it's code-coverage-based stress tests, symbolic execution, or static analysis. I think static analysis would do best here." Which is basically what I've been trying to say. Given that this keeps repeating itself over time by people that are quite smart adds credence to my assertion that the more average folks are in for even bigger issues if they come near this area... > Note that as of this week there are still linux kernel patches > that mention leap second issues > http://www.spinics.net/lists/stable/msg35597.html interesting :) Warner _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
