To sum up what I got from the comments regarding the threading API, do we agree that we only want to basically to mimic the underlying C-Init, that is: - provide an environment ctor with only one preferred threading support level. - provide a query method to probe the provided support level (user code will need to check if it is ok with it). - scan the documentation and make sure that any usage of such a ctor is followed by a checking of the provided level ? - if no level is provided, assume "threading::single" (which we do not need to test, since that the minimal level)
If that ok, I'll try to provide a patch accordingly. Thanks On Thu, 2012-11-29 at 12:04 -0600, Hal Finkel wrote: > ----- Original Message ----- > > From: "Matthias Troyer" <[email protected]> > > To: "alain miniussi" <[email protected]> > > Cc: "Discussion of Boost.MPI development" <[email protected]> > > Sent: Thursday, November 29, 2012 7:21:09 AM > > Subject: Re: [Boost-mpi] Thread API > > > > > > On Nov 29, 2012, at 1:11 PM, Alain O Miniussi <[email protected]> > > wrote: > > > > > > That being said, I do not have a strong opinion between: > > > a) provide a 2 argument ctor > > > b) provide one argument ctor, and test provided level afterward. > > > > > > I just have a preference for b, because I find it simpler (both in > > > terms > > > of API and explanation, one thing I did not mention is that we > > > could as > > > weel abort if the requirement is not met in the ctor, since we > > > won't be > > > able to do any MPI related stuff after that, so going into a lot of > > > trouble to explain the status of env seems unjustified), and that > > > throwing in ctor has it's own set of issue (if only being > > > controversial). > > > > Actually throwing in the constructor if we cannot acquire a resource > > (here MPI with required level of thread support) is just the RAII > > idiom. There are no problems with that and it is actually good > > style. > > > > > > One thing to consider is that if the requirement is not met, we > > > probably > > > want to explain what's going on to the user. Which will require > > > some > > > code. So the test "if (provided < required) { ... }" won't add a > > > lot of > > > trouble anyway. > > > > I agree. If the requested level is not met we will need to test > > anyway which level we got. > > Fair enough. Maybe the best thing to do is just to make sure that we actually > do this test is all of the documentation snippets and example code. > > -Hal > > > > > Matthias > > > > > > _______________________________________________ > > Boost-mpi mailing list > > [email protected] > > http://lists.boost.org/mailman/listinfo.cgi/boost-mpi > > > -- Alain Miniussi Responsable Tech. Centre de Calcul Haute Performance Obs. de la Côte d'Azur |Mont Gros: +33 4 92 00 30 09 BP 4229 |Sophia : +33 4 83 61 85 44 06304 Nice Cedex 4 |https://crimson.oca.eu _______________________________________________ Boost-mpi mailing list [email protected] http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
