Proposal for Requiring Save/Restore of Sets and Tags

seol at scorec.rpi.edu seol at scorec.rpi.edu
Tue Oct 26 09:54:16 CDT 2010


>
>         iMesh: No cycles in set-inclusion and prnt-chld graph
>             Proposer: Carl
>             Status: RATIFIED
>             impact: iMesh_unitTest tests for this. Implementation is
>                 expected to return error if caller attempts to create
>                 a cycle.

We have no strong objection to no cycle constraint with entity set unless we have a demand of cyclic entity set with
use case.

In terms of iMesh_set/getErrorCheckingLevel proposal, I don't see the benefit of setting/getting the error checking
level implemented at the implementation level. On which level the application will take advantage of the
implementation's error information doesn't seem to be what implementation should provide. In other word, for
generality, implementation should return error code no matter what the desired error level is needed for the
application. If we choose to accept this proposal, this shall affect all itaps implementations for consistency.

Seegyoung


>
> In other libraries I have designed where I've faced similar issues, I've
> had the ability to allow the client to turn on and off expensive error
> checking routines. That way, you can specify what is and is not
> erroneous use of the API without forcing the client (and the library) to
> always pay the price to check for it. The client is then responsible for
> turning checks on when 'things are going wrong'  and only if the lib
> fails to detect any problems can they submit a valid bug report.
> Something like this...
>
> enum iBase_ErrorCheckLevel {
>     iBase_NONE,      /* do NO error checking */
>     iBase_MINIMAL,   /* do minimal cost error checking (e.g. pointer != NULL) */
>     iBase_MEDIUM,    /* error checks where cost is noticeable in performance but not significant */
>     iBase_MAXIMAL    /* all error checks regardless of cost */
> };
>
> void iMesh_setErrorCheckingLevel(iMesh_Instance instance,
>     int level, int *err);
>
> void iMesh_getErrorCheckingLevel(iMesh_Instance instance,
>     int *level, int *err);
>
> In an implementation, given any error checking code block, the cost of
> that block is always rated relative to the 'real work' the library is
> there to do. So, during a save or load which involves disk I/O, checking
> the entire set inclusion graphs for cycles might be ok as the save load
> process may well be traversing the whole graph anyways. So, there,
> checking for cycles may be considered 'low' cost and the conditional
> logic controlling it would be something like
>
> if (error_level >= iBase_MINIMAL)...
>
> However, in a createEntSet call, the cost of traversing the whole graph
> to see if a cycle is being created would be considered a high cost and
> so conditional logic to trigger that check there would be something
> like...
>
> if (error_level == iBase_MAXIMAL)
>
> Taking an approach such as this does give us much more flexibility in
> dealing with performance vs. spec robustness (e.g. not so many
> implementation defined behaviors) issues.
>
> 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
>
>




More information about the tstt-interface mailing list