Issue 11317: Does it make sense to change the module encapsulation for Monotonicity?                                                                                                                                 (evot-ftf)
Source: SELEX SI (Mr. Fabrizio Morciano, fmorciano@selex-si.com)
Nature: Uncategorized Issue
Severity: 
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);
};


};


Resolution: To introduce a specific module “Monotonicity” to be nested into cosClockService module.
Revised Text: To substitute IDL described in Section 8.8 with module CosClockService { module Monotonicity { enum RecoveryStrategy { 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 RecoveryStrategy 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); }; }; };
Actions taken:
August 29, 2007: received issue
April 15, 2008: closed issue
Discussion: 


End of Annotations:=====
s is issue # 11317

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

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);
};


};