I believe the test is intended strictly for Linux threads. I don't believe we have ever (intentionally) supported any other thread library in such environments.
I'll leave it to Jeff to decide if he feels this is an issue. On Mar 15, 2011, at 4:27 PM, Paul H. Hargrove wrote: > I'd like to point out that it is libpthread and the arguments it passes to > clone(), NOT the Linux kernel version, that is the determining factor (at > least if you have a 2.6.x kernel). The "LinuxThreads" implementation of > Pthreads will give the one-pid-to-rule-them all behavior, while the NPTL > implementation gives unquie pids under any 2.6.x kernel and even w/ some > 2.4.x kernels from Red Hat. > > I have encountered systems on which dynamic linking gave NPTL and static > linking gave LinuxThreads. That is a "gottcha" that I am not certain Jeff > and Ralph have taken into account. > > Note that I have no objection to "we don't support this", but fear that > detection of that situation may be flawed. > > -Paul > > On 3/15/2011 2:14 PM, Ralph Castain wrote: >> Hi folks >> >> Jeff and I encountered a problem when cross-compiling OMPI for Linux. Turned >> out that we had an old test in the code that looked for threads to have >> different pids. Since it couldn't be tested when cross-compiling, the test >> simply assumed this was the case for Linux under those conditions - which >> broke the build for current Linux kernels. >> >> Different pids for threads was last seen in the old RH 4 series (kernel >> 2.6.9 or so). Some code (e.g., waitpid) was also provided to support this >> unusual situation - this code was in fact broken when we updated the event >> library. So even if we were in an old kernel, the code base would neither >> compile nor run. >> >> Rather than trying to continue to support these old kernels, we have removed >> all the stale code that was covered by OPAL_THREADS_HAVE_DIFFERENT_PIDS. >> This removed some complexity from a few PLM modules and removed the broken >> code. >> >> Jeff modified the corresponding .m4 test so we now detect an older kernel, >> print out a nice "we don't support this" message (along with noting that >> earlier versions of OMPI do), and then abort the build. >> >> If you know of some reason to restore support for old Linux kernels, and >> someone willing to do the work to "refresh" that support, please let us know. >> >> Ralph& Jeff >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > HPC Research Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
