[petsc-dev] MatNullSpaceDestroy
Barry Smith
bsmith at mcs.anl.gov
Thu Mar 24 11:43:27 CDT 2011
> o now MatNullSpace instances cannot be freed with
> PetscObjectDestroy()... This change broke bad petsc4py Python+PETSc
> refcounting management. BTW, PetscObjectDestroy() does not take a
> pointer... And IMHO PetscHeaderDestroy should also take a pointer...
Thank you for the explanation. petsc4py relies on PetscObjectDestroy() which won't work when some destroys take & and some don't. I didn't know you needed PetscObjectDestroy() to always work.
The correction solution is to switch to using the & in all destroys. It sounds like this has to happen sooner rather than later.
Barry
On Mar 24, 2011, at 11:28 AM, Lisandro Dalcin wrote:
> On 23 March 2011 20:09, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>> On Mar 23, 2011, at 5:58 PM, Lisandro Dalcin wrote:
>>
>>> Are you going to rename MatNullSpaceDestroy -> MatNullSpaceDestroy_
>>> and add the backward compatibility #define? Changeset 1a6f5fc1c27b
>>> broke petsc4py...
>>
>> No, it was changed to the &object paradigm.
>>
>> Basically what is happening now is that commonly used destroys are changed with the _ paradigm
>>
>> Uncommonly used destroy are fixed to use the &object paradigm.
>>
>> Don't like the fact that there are two paradigms well I could change everything to & immediately :-(
>>
>
> Barry, whatever you want to do, please be consistent :-)... The lines
> below are from MatNullSpaceCrete
>
> /* cannot use MatNullSpaceDestroy() as generic destroy function
> because it takes pointer to the object */
> ierr = PetscHeaderCreate(sp,_p_MatNullSpace,int,MAT_NULLSPACE_CLASSID,0,"MatNullSpace",comm,0,0);CHKERRQ(ierr);
>
> So now MatNullSpace instances cannot be freed with
> PetscObjectDestroy()... This change broke bad petsc4py Python+PETSc
> refcounting management. BTW, PetscObjectDestroy() does not take a
> pointer... And IMHO PetscHeaderDestroy should also take a pointer...
>
> Barry, please, just reconsider this and make MatNullSpaceDestroy
> follow the same pattern as Object, IS, Vec, Mat, etc.
>
> PS: I still think all this is going to be a mess... now one commented
> about my previous proposal about a compatibility header. what's wrong
> with that?
>
> --
> Lisandro Dalcin
> ---------------
> CIMEC (INTEC/CONICET-UNL)
> Predio CONICET-Santa Fe
> Colectora RN 168 Km 472, Paraje El Pozo
> 3000 Santa Fe, Argentina
> Tel: +54-342-4511594 (ext 1011)
> Tel/Fax: +54-342-4511169
More information about the petsc-dev
mailing list