On Oct 24, 2012, at 6:38 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
>> >> This is a pretty valuable use case, and I'm inclined to fix it, but >> it could be a major change and I don't want to jump into it without >> thinking it through… > > Agreed. > > The big problems seem to be backwards compatibility and per-object > data storage. > > 1) I assume we don't want to break the code of everyone using > libMesh::processor_id(), etc? But if libMeshInit's constructor sets a > global pointer to "this", then global functions could grab > previously-global state through that pointer, and only > multi-LibMeshInit-aware apps would need to switch to > my_libmesh->processor_id() instead. Right, I think maintaining backwards compatibility with the API will be no problem. > 2) How many of our classes would need to start stashing a > pointer-to-LibMeshInit so they'd be multi-LibMeshInit compatible? I > suppose only the MPI/TBB aware classes would need this, and they're > all heavyweight enough that an extra pointer wouldn't matter? This I'm actually afraid of - but to find out I'm going to start by removing the default communicator argument (temporarrity!) from the Parallel:: methods and see what happens. What really scares me is everywhere there is a parallel_verify() or whatever the communicator will need to be passed in, which means access to the LibMeshInit (or some lighter-weight object). The API would be hardly different - pass an optional LibMeshInit object to the Mesh, and then it takes care of the rest - but the internals I'm honestly a little worried about! -Ben ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
