On Nov 2, 2013, at 7:51 AM, Matthew Knepley <[email protected]> wrote:
> On Fri, Nov 1, 2013 at 11:27 PM, Jed Brown <[email protected]> wrote: > Barry Smith <[email protected]> writes: > > > hence are not thread safe. Is there any decent way to deal with this? > > Make those variables thread local? Or make the database an object > instead of a collection of global variables, in which case it can be > cloned for each thread to access (and manipulate). > > We could. It seems like our usual policy for carrying state around is to > shove it in > a PetscObject. What was the rationale for these functions not taking an > object? They are in an object, but they are global otherwise the object would have to be carted around through all the calls everywhere. Every routine that uses PetscOptionsBegin or head would have to take that object as an argument, and unfortunately this is all over the place. Barry > > Matt > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener
