On 16 Jan 2019, at 15:41, Hapla Vaclav via petsc-dev <petsc-dev@mcs.anl.gov<mailto:petsc-dev@mcs.anl.gov>> wrote:
On 16 Jan 2019, at 15:28, Jed Brown <j...@jedbrown.org<mailto:j...@jedbrown.org>> wrote: Hapla Vaclav via petsc-dev <petsc-dev@mcs.anl.gov<mailto:petsc-dev@mcs.anl.gov>> writes: So is it wise to do that as Matt wrote? It would basically make PetscViewerSetFromOptions() non-reentrant. I think non-idempotent is the word you're looking for here. Reentrancy refers to being able to call the function from an interrupt handler and similar circumstances. https://en.wikipedia.org/wiki/Reentrancy_(computing) Sure :-) I think PetscViewerSetFormat could be undeprecated (but marked as developer level to steer people toward PetscViewerPushFormat) or PetscViewerSetFromOptions could just set viewer->format directly. Agree. Let's just set viewer->format directly so no need for undeprecation. But what to do with the current stack (viewer->formats)? See https://bitbucket.org/petsc/petsc/src/master/src/sys/classes/viewer/interface/viewa.c#lines-145 https://bitbucket.org/petsc/petsc/src/master/src/sys/classes/viewer/interface/viewa.c#lines-95 Should I just ignore the stack? If I see it well, overwriting current viewer->format shouldn't cause any harm. If there is Push before and Pop after Set, that Pop should just set the value prior to Push. Which I think makes sense. Done in https://bitbucket.org/petsc/petsc/pull-requests/1324/ Vaclav
