On Feb 15, 2011, at 8:23 PM, Matthew Knepley wrote:

On Tue, Feb 15, 2011 at 8:18 PM, Barry Smith <[email protected]> wrote:

On Feb 15, 2011, at 8:12 PM, Matthew Knepley wrote:

...

On Tue, Feb 15, 2011 at 8:10 PM, Barry Smith <[email protected]> wrote:

On Feb 15, 2011, at 8:03 PM, Matthew Knepley wrote:

...

On Tue, Feb 15, 2011 at 7:58 PM, Barry Smith <[email protected]> wrote:

On Feb 15, 2011, at 5:26 PM, Matthew Knepley wrote:

...

On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <[email protected]> wrote:

In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to set the pointer explicitly to 0 after the object is destroyed.

In Petsc XXXDestroy() does not pass the pointer (because it seemed too unnatural to me in 1994) thus not allowing 0ing the pointer.

Was this a bad design decision? Should it be revisited?

Barry

Two use cases

1) error detection when someone tries to reuse a freed object

We catch this with other error detection. I do not think we would gain much here.

No really. If I do MatDestroy(mat); MatMult(mat,x,y); then it is possible that MatMutl() will crash while looking around inside where mat points. If MatDestroy(&mat); zeroed mat then MatMult(mat,x,y) could do the safe test of if (!mat) nice error message.

I agree, but the immediate type test at the start of MatMult() has caught most things for me. I do not consider double-free a recoverable error, so a SEGV is alright here as well.

If I am sitting in front of a Matlab or Python scripting session I would much prefer an error that returns to my Matlab or Python prompt so I can keep on doing stuff versus a crash that requires restarting Matlab or Python.

I do not disagree with this. However, we do have to weigh the effectiveness of changes that break every PETSc code ever written.

True. But just because I did something stupid 16 years ago doesn't mean we should live with it forever. What about introducing XXXXFree() and moving to using it exclusively in PETSc but continuing to support XXXDestroy() for years.

That is a good solution. I guess I am alright with XXXFree() although I like Destroy better. I can't think of a better name.

To make live hard we'll make a new version of PetscFree() that zeros the pointer and call it PetscDestroy() :-)

Should be release before we do this?

Yes Barry

Matt

...

Matt

Barry

...

Matt

Barry

...

2) when removing some objects from a data structure that will be used data one currently needs to do

XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0;

instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr);

True, but again I do not think the win is large.

Matt

-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener