------- Comment #5 from bkoz at gcc dot gnu dot org 2008-01-18 23:22 -------
Brain dump into this: reasons to move to datum/mt_allocator type approach: It tries to be the minimal change, keeping all your existing data. (With the exception of making a tristate variable for the force_parallel/force_sequential stuff.) What it does is make __gnu_parallel::Settings into a datum that has two static accessors, Settings::get and Settings::set methods. Then, when one needs a config parameter, they do const __gnu_parallel::Settings& s = __gnu_parallel::Settings::get(); And then access the settings data via s.partition_minimal_n; etc. Let me know what you think about this. Hopefully it adds something more concrete to our discussions. I didn't do the rest of the patch, which is to fix up the current accesses. I wanted to make sure we are on the same wavelength here first, design-wise. The advantage of doing things in this general way is: 1) Actual settings are private, internal to the library binary. 2) Only two exports are needed: the get and set methods 3) Can add (but not subtract) from settings datum later on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34797
