Sorry, I stated my facts backwards.
CORRECTED facts:
+The old "LinuxThreads" implementation is the one that gave DIFFERENT
pids to each pthread.
+ "NPTL" is the current implementation of Pthreads for Linux, and the
one giving a single pid shared by all pthreads.
So, I hope Ralph's statement is similarly reversed, because
"LinuxThreads" as not been maintained in years.
-Paul
On 3/15/2011 3:40 PM, Ralph Castain wrote:
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
_______________________________________________
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
