[mpich-devel] helpful preprocessor check for CPU_ZERO and CPU_SET
Jeff Hammond
jhammond at alcf.anl.gov
Mon Dec 31 14:17:22 CST 2012
I don't disagree at all with your reasoning here and would certainly
favor the definition of __USE_GNU at the top level, but that's a much
more invasive change.
The Linux kernel documentation
http://www.kernel.org/doc/man-pages/online/pages/man3/CPU_SET.3.html
demonstrates the usage that is currently in MPICH as well as in
numerous examples on the Internet...
Best,
Jeff
On Mon, Dec 31, 2012 at 2:12 PM, William Gropp <wgropp at illinois.edu> wrote:
> For many cases like this, the best solution is either
>
> Never use any macro that starts with __ (these should be reserved "for the system")
>
> If you must, it needs to be defined early, including *before* any configure tests on capabilities of the headers or the compiler, since these macros (e.g., __USE_GNU etc.) *change* the language that is implemented. It is a serious error to define this within any header file, other than the configuration file (mpichconf.h in our case).
>
> Adding it to any other header file should always be considered a mistake.
>
> Bill
>
> William Gropp
> Director, Parallel Computing Institute
> Deputy Director for Research
> Institute for Advanced Computing Applications and Technologies
> Paul and Cynthia Saylor Professor of Computer Science
> University of Illinois Urbana-Champaign
>
>
>
> On Dec 31, 2012, at 12:54 PM, Jeff Hammond wrote:
>
>> Having been frustrated in a related development effort because I was
>> unaware that sched.h was previously and indirectly included without
>> the __USE_GNU macro active, thereby preventing me from using CPU_ZERO
>> and CPU_SET, I suggest the inclusion of the following preprocessor
>> macro in MPICH so that it is plainly obvious should this occur in the
>> future due to the prior inclusion of sched.h before the following
>> code, which is actually quite far down in the source.
>>
>> I recognize that this is currently not a problem nor is the code below
>> even active right now, but (1) should it ever be active and (2) some
>> developer includes sched.h without __USE_GNU prior to line 1050 in
>> this file (there are ~10 MPICH internal headers that could cause this
>> right now), there will be a problem that is only detected when e.g.
>> cpi is linked, which is later than one would otherwise prefer.
>>
>> Best,
>>
>> Jeff
>>
>> $ svn diff pm/util/process.c
>> Index: pm/util/process.c
>> ===================================================================
>> --- pm/util/process.c (revision 10808)
>> +++ pm/util/process.c (working copy)
>> @@ -1031,6 +1031,11 @@
>> #define __USE_GNU
>> #endif
>> #include <sched.h>
>> +
>> +#if !defined(CPU_ZERO) || !defined(CPU_SET)
>> +#error CPU_ZERO and/or CPU_SET were not defined because of prior
>> inclusion of sched.h without __USE_GNU
>> +#endif
>> +
>> /*
>> * Set the processor affinity for the calling process. Normally, this will
>> * be used in the "postfork" routine provided by the process manager, before
>>
>> --
>> Jeff Hammond
>> Argonne Leadership Computing Facility
>> University of Chicago Computation Institute
>> jhammond at alcf.anl.gov / (630) 252-5381
>> http://www.linkedin.com/in/jeffhammond
>> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
>
--
Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammond
https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
More information about the devel
mailing list