Why not go all the way and remove PetscInitialize()? The various initializations in there could also be done “on the fly, as needed” also with locks to make them safe. Why are some initializations done at startup and some done “as needed”?
Barry On Nov 10, 2013, at 8:31 AM, Jed Brown <[email protected]> wrote: > Matthew Knepley <[email protected]> writes: >>> 2) We need a way for initializing all the packages in PetscInitialize() >>> instead of as needed. In master I see >>> >> >> I really do not like this since then we are creating circular dependencies, >> and people who would like to "use >> only a part" will be upset. What about having the user who wants completely >> threadsafe stuff call *Initialize(), >> and then have this cascade all the way down (I think it should anyway). > > Why is it not enough to have a lock for initialization (or anything else > that needs to modify the remaining globals)? Those functions are not > performance-sensitive, so the locking strategy need only be immune to > deadlock, not high-performance.
