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

[Matthew Knepley]

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.

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