[petsc-dev] What is wrong with CHKERRQ() after PetscInitialize()?

[Jed Brown]

On Mon, Sep 17, 2012 at 8:20 PM, Matthew Knepley <knepley at gmail.com> wrote:

> If a caller does not want to abort if PetscInit fails, alright.
>
> However, we can still return a special error code that never goes into the
> infrastructure.
>

Hmm, the first couple lines of PetscInitialize has

  PetscFunctionBegin;
  if (PetscInitializeCalled) PetscFunctionReturn(0);

  /* these must be initialized in a routine, not as a constant declaration*/
  PETSC_STDOUT = stdout;
  PETSC_STDERR = stderr;

This could fail if

1. PetscInitialize did not match __FUNCT__ (checking would use PETSC_STDERR
before it was initialized)

2. PetscThreadLocalGetValue(petscstack, PetscStack*) fails. Actually, I
would expect this to fail any time thread local variables are not supported:

#define PetscThreadLocalGetValue(name,type) (
(type)pthread_getspecific(name##_key))


In any case, maybe we can say that it is safe to CHKERRQ after
PetscInitialize because there is no code path by which it could fail?
PetscInitialize itself starts calling CHKERRQ for everything after this
part.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120917/177dc66b/attachment.html>