[mpich-devel] helpful preprocessor check for CPU_ZERO and CPU_SET

[Darius Buntinas]

If we are defining __USE_GNU et al. other than in the top-level config file, we need to fix that!

-d

On Dec 31, 2012, at 2:17 PM, Jeff Hammond wrote:

> 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