EVoT 2.0 NO IDEA Avatar
  1. OMG Issue

EVOT2 — Does it make sense to change the module encapsulation for Monotonicity?

Open Closed All
  • Key: EVOT2-9
  • Legacy Issue Number: 11317
  • Status: closed  
  • Source: Selex ES ( Fabrizio Morciano)
  • Summary:

    On 8.8

    Does it make sense to change the module encapsulation for Monotonicity?

    I'd propose

    module Monotonicity
    {
    enum RecoveyStrategy

    { IGNORE, // Ignore violation SLOW_DOWN, // Slow down the clock so to recover monotonicity STALL // Stall the clock up to when the violation condition has been risolved }

    ;

    struct Violation

    { long min_interval; // minimum time interval (in nsec) to be considered as a violation long max_interval; // max time interval (in nsec) to be considered as a violation. Greate interval // will be regarded as clock failure RecoveyStrategy strategy; }

    ;

    local interface ViolationHandler;
    local interface ViolationRegistry

    { // Register an handler for a given clock providing the monotonicity recovering strategy. // By default the monotonicity violation are ignored. void register_handler(in Clock aClock, in Violation aViolation, in ViolationHandler aHandler); void unregister_handler(in ViolationHandler aHandler); }

    ;

    local interface ViolationHandler

    { // void handle_violation(in Clock aClock, in Violation aViolation); }

    ;

    };
  • Reported: EVoT 2.0b1 — Wed, 29 Aug 2007 04:00 GMT
  • Disposition: Resolved — EVoT 2.0
  • Disposition Summary:

    To introduce a specific module “Monotonicity” to be nested into cosClockService module.
  • Updated: Fri, 6 Mar 2015 20:58 GMT