Christian, I think the module status, as currently proposed, is ill defined. Instead of vague verbal descriptions, such as "ok", "error", "bad error", "very very bad error", we should give a functional definition of what happens to the event processing when a module returns a given status. Then we can name the statuses according to what they *do* and the module writers would know what to return when. Only 4 things can happen depending on the module status: 1) the next module in the pipeline is invoked. Call this the "ok" status. 2) the event processing stops normally. This could be returned by a trigger latch filter module. Call this the "stop" status. 3) the event processing stops with an error. This could be returned a module to signal a problem with the event, for example missing or invalid input data, or a transient internal error. Call this the "error" status. 4) the whole application stops. This could be returned by a module when further processing is meaningless or dangerous, and is returned as an alternative to calling exit(), abort() or assert(). Examples are: missing calibration data, corrupted private data, gross system malfunction (2+2 produces 5 or sin(x)>1, sometimes happens when using -O compiler switches or porting code to Alpha and x86 CPUs). Call this "abort" status. -- Konstantin Olchanski Physics Department, Brookhaven National Laboratory, Long Island, New York olchansk@bnl.gov
This archive was generated by hypermail 2b29 : Sun Jan 21 2001 - 11:32:22 EST