This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/34797] [parallel mode] Settings are separated for each compilation unit
- From: "bkoz at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Jan 2008 23:22:48 -0000
- Subject: [Bug libstdc++/34797] [parallel mode] Settings are separated for each compilation unit
- References: <bug-34797-15092@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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