| |||||||||||||
The timer API: size or type safety?The timer API: size or type safety?Posted Dec 7, 2006 21:47 UTC (Thu) by malor (subscriber, #2973)Parent article: The timer API: size or type safety?
"[...]which if we get it wrong produces a /very/ trivial crash that is trivial to fix[....]"
On production systems, there's no such thing as a trivial crash.
(Log in to post comments)
The timer API: size or type safety? Posted Dec 7, 2006 23:09 UTC (Thu) by iabervon (subscriber, #722) [Link] On production systems, a trivial crash is one that crashed the test system and got fixed before it went into production. The argument is that it would be difficult to write code which would pass a cursory code review and would ever work (particularly with debugging enabled), so chances are that such bugs wouldn't get anywhere.
The timer API: size or type safety? Posted Dec 8, 2006 0:42 UTC (Fri) by liljencrantz (subscriber, #28458) [Link] Fail-fast bugs are certainly better than fail-slow bugs. But I belive you place far to much trust in test coverage. In a complex, concurrent system like a kernel, there will always be code paths that aren't covered by any test cases, even ones using long test periods and real use cases.
The timer API: size or type safety? Posted Dec 8, 2006 15:57 UTC (Fri) by iabervon (subscriber, #722) [Link] Oh, the error paths get terrible coverage. This particular case, however, is looking up the data required for a timer callback. If the timer fires at all, it is almost certain to trigger any bug of this form immediately, because it's standardly unconditional at the beginning of the callback. If this isn't getting tested, a bug is more likely to be that the function does something totally wrong (since it wasn't tested at all) than that the type of the argument is wrong.
|
|||||||||||||