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

[Barry Smith]

On Sep 17, 2012, at 8:31 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 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.

    Is that correct?