Repository navigation
initialize and finalize and destroy #155
Description
Do we ever see a use case where we might have something like:
PETSc.initialize(petsclib)
# ... work....
PETSc.finalize(petsclib)
# start PETSc again...
PETSc.initialize(petsclib)I ask because this can cause problems with the garbage collector in when it's used. For instance, if the garbage collector is run on a PETSc object allocated in the first chunk of work AFTER petsc has been re-initialized this is an error since the actual PETSc object doesn't exist anymore. The destroy has a check for whether PETSc is finalized, but this will not catch PETSc having been re-initialized.
Activity
[-]initialize and finalize[/-][+]initialize and finalize and destroy[/+]boriskaus commentedon Aug 6, 2021
I see no reason why this would be done. In the testing we do this but with a
finalizeat the endpsanan commentedon Aug 6, 2021
PETSc supports this. It is done sometimes in practice because someone uses PETSc within a larger code and wants to encapsulate as much as possible, so they initialize and finalize PETSc for each solve.
Is it already an issue without the second
initialize()? You aren't allowed to destroy PETSc objects after you finalize PETSc.jkozdon commentedon Aug 6, 2021
That is true, but we catch it with a check to see if PETSc is finalized
PETSc.jl/src/mat.jl
Lines 191 to 195 in 73f12e0
OK. I have a few ideas for how to work around this, so will leave the issue open. Some smarter people than me may weigh in as well.
filoferra commentedon Sep 11, 2026
The age mechanism does both:
petsclib.ageis bumped on initialize and finalize, every object records the age it was created under.isdestroyablecompares them, so a handle from a previous cycle is a no-op instead of a crash. Fixed in #252