Proposal for Requiring Save/Restore of Sets and Tags

[Mark Miller]

> 
> I don't have a strong opinion about this.  But I am adamantly opposed to
> requiring implementations to check for and refuse to create cyclic graphs.
> We do some stuff involving very large graphs (e.g. millions of sets).  The
> performance penalty would be significant.  And we already correctly handle
> cyclic graphs in queries.

So, this was a concern I had regarding this change proposal...

        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.

the performance cost of having to do that each time the client creates a
set and/or prnt/chld link seems prohibitive.

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