Run-Time vs. Config-time error checking controls

[Mark Miller]

On Thu, 2010-10-21 at 09:35, Carl Ollivier-Gooch wrote:
> My memory is that we had already agreed that an implementation is free 
> to skip expensive (and even cheap) checks when compiled in release mode, 

So, I don't recall there being an ITAPS-wide, agreed upon config-time
switch names to control this. Do we have any defined?

I know projects like HDF5 use something like --enable-production or
--enable-debug but I don't honestly know what the adopted 'ITAPS-way'
for this is, if there is one. If not, we might ought to propose one
ASAP.

> though it should do all checks in debug mode.  The latter is very 
> important to help developers debug code, but once it's working (i.e., 
> nothing stupid being done by accident), a lot of those checks are 
> unnecessary, so turning them off for release code is no problem. 
> Conditionally-defined macros will do this.  As Mark said, there are 
> run-time configurable methods for this, too, though I suspect they add a 
> small amount of overhead in practice.

There are indeed config-time ways of managing the amount of work a
library is required to perform for error-checking, etc. And, honestly,
if the ITAPS project as a whole wants to do it using ONLY a config-time
control mechanism, I think that would be ok.

My very strong personal preference, based on a lot of experience with
this kind of thing though, is a run-time check the default behavior of
which is controlled at config-time.

If you config for 'release mode', the checks are OFF by default but can
be turned ON at run-time. If you config for 'development mode', the
checks are ON by default but can be turned off at run-time.

Finally, the run-time controls consist of a) a function in the library
an application can call to affect ON/OFF control and b) an env. variable
or command line argument a user can set to override everything else
(note that a command-line argument appraoch would require a change to
iMesh_newMesh to accept argc/argv from the command line much like
MPI_Init does).

Yeah, there is probably a tiny, imperceptable, run-time cost associated
with doing it this way. However, the flexibility it affords has always
trumped concerns for that ;)

Mark



-- 
Mark C. Miller, Lawrence Livermore National Laboratory
================!!LLNL BUSINESS ONLY!!================
miller86 at llnl.gov      urgent: miller86 at pager.llnl.gov
T:8-6 (925)-423-5901    M/W/Th:7-12,2-7 (530)-753-8511