[petsc-dev] PetscOptionsBegin etc all use global variables

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:
>    What are “internal functions” in PETSc?

I mean functions marked "Level: advanced".

>    Why not just grab the appropriate global indexed by the thread as
>    needed instead of “passing it to the “internal functions”? That is
>    why do some functions “grab the thread local object” while other
>    functions "take the thread local object as an argument explicitly”?

I think that if we offer it, there will be times where it will be useful
to have multiple configurations, perhaps provided in different files,
that are not based on threads.  In that setting, we could instantiate
multiple PetscOptions objects and pass them around, perhaps setting them
explicitly on a given object "consult this database when looking for
your options".  Of course defaults are important and we don't want to
force the ordinary user to deal with that, thus we need a
global/thread-local variable where objects can get their databases.

>    It also seems that there are two distinct decisions that do not have to be made together
>
> 1)  Keep all global state in a single global object, instead of one for stack, one for options, one for …
>
> 2) Index global objects by thread.
>
>     We can do 1 and 2, 2,  or 1 (1 by itself would not support threads) 
>
>     But regardless it seems like a bit of refactoring, not one day of
>     work that we could be confident would work well as a long term
>     solution?

I agree.

>     Is there anything good we can tell our current user Ed who wants to do something now?

Can he serialize the configuration step across his threads?  Does ho
need to dynamically reconfigure at any old time?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131103/530aa817/attachment.sig>