[petsc-dev] setting viewer format from options

[Hapla Vaclav]

On 16 Jan 2019, at 15:41, Hapla Vaclav via petsc-dev <petsc-dev at mcs.anl.gov<mailto:petsc-dev at mcs.anl.gov>> wrote:



On 16 Jan 2019, at 15:28, Jed Brown <jed at jedbrown.org<mailto:jed at jedbrown.org>> wrote:

Hapla Vaclav via petsc-dev <petsc-dev at mcs.anl.gov<mailto:petsc-dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190116/3c889af0/attachment.html>