I like the updated glossary - very good summary of the relevant terminology and common points of confusion. One minor gripe below (and it *is* minor, despite the amount of text explaining my point of view...)
On Tue, Apr 24, 2012 at 11:58 AM, Jim Jewett <jimjjew...@gmail.com> wrote: > Real Time > --------- > > Time in the real world. This differs from `Civil time`_ in that it is > not `Adjusted`_, but they should otherwise advance in lockstep. > > It is not related to the "real time" of "Real Time [Operating] > Systems". It is sometimes called "wall clock time" to avoid that > ambiguity; unfortunately, that introduces different ambiguities. "Not related" is simply not true, as this is the exact meaning of "Real Time" in the term "Real Time Operating System". In the PEP's terms, a Real Time OS is simply an operating system specifically designed to allow developers to meet deadlines expressed as the maximum permitted Real Time Duration between an event occurring and the system responding to that event. The power an RTOS gives you over an ordinary OS is sufficiently low level control over the scheduler (if there's even an entity worth of the name "scheduler" at all) such that you can *demonstrably* meet hard real time deadlines (down to a certain lower limit, generally constrained by hardware). It's a pain to program that way though (and adequately demonstrating correctness gets harder as the code gets more complicated), so you often want to use a dedicated processor for the RTOS bits and a separate processor (with an ordinary OS) for everything else. (There's a good explanation of many of these concepts, include separating the hard realtime parts from everything else, in the Giant Robots of Doom talk from PyCon AU 2010: http://pyvideo.org/video/481/pyconau-2010--hard-real-time-python--or--giant-ro) One interesting aspect of using a normal OS is that you can *never* reliably read a Real Time clock in user level code - the scheduler doesn't provide adequate guarantees of responsiveness, so there's always going to be some scheduling jitter in the results. This generally doesn't matter for measuring durations within a machine (since the jitter will, with a sufficiently large number of samples, cancel out between the two measurements), but can be a problem for absolute time measurements that are intended to be compared with high precision across different machines. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
