[petsc-dev] XXXDestroy() mistaken design in PETSc

[Matthew Knepley]

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. Should be release before we do this?

   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110215/a37520d7/attachment.html>