On Feb 15, 2011, at 8:23 PM, Matthew Knepley wrote: > On Tue, Feb 15, 2011 at 8:18 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On Feb 15, 2011, at 8:12 PM, Matthew Knepley wrote: > > > On Tue, Feb 15, 2011 at 8:10 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > > > On Feb 15, 2011, at 8:03 PM, Matthew Knepley wrote: > > > > > On Tue, Feb 15, 2011 at 7:58 PM, Barry Smith <bsmith at mcs.anl.gov> > > > wrote: > > > > > > On Feb 15, 2011, at 5:26 PM, Matthew Knepley wrote: > > > > > > > On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <bsmith at mcs.anl.gov> > > > > 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
