Barry Smith <[email protected]> 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?
pgpSaSAGJjjRk.pgp
Description: PGP signature
