GraphBLAS / graphblas-api-c

Other
7 stars 3 forks source link

"input-only" parameters when an error occurs #41

Closed DrTimothyAldenDavis closed 2 years ago

DrTimothyAldenDavis commented 2 years ago

The draft spec states:

If a GraphBLAS method returns with any execution error other than GrB_PANIC, it is guaranteed that the state of any argument used as input-only is unmodified. Output arguments may be left in an invalid state, and their use downstream in the program flow may cause additional errors. If a GraphBLAS method returns with a GrB_PANIC execution error, no guarantees can be made about the state of any program data. [Scott: Is this statement true of input arguments?]

I think this should be revised. Say I am computing C=A*B with GrB_mxm, and A has pending operations. I first need to finish the pending work on A. If that computation fails (out of memory, for example), then it can be that A is left in an invalid state, or a partially-computing state, so instead of returning a manged A matrix, I simply free all of its contents. This is true for a GrB_PANIC as well. The matrix A is "input-only" in a mathematical sense, but it is "input/output" in a computational sense, if it has pending work.

Even if the GrB_mxm succeeds, it has returned the "input-only" matrix A as modified, with pending work finished.

If the matrix A has been finished with GrB_Matrix_wait (A, mode), then there can be guarantees about GrB_mxm not modifying it if an error occurs. I don't see how I can guarantee anything about A if I have to do work on it.

The spec does not define the term "input-only". Since all objects can have pending work, almost all parameters to a GrB method are "input/output".

mcmillan03 commented 2 years ago

Duplicate of #57

joseemoreira commented 2 years ago

Duplicate. Will handle in 2.1.