This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/34797] [parallel mode] Settings are separated for each compilation unit



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]