I have looked before for symbols to distinguish LinuxThreads from NPTL,
but I was not successful in finding anything. I don't recall if I
examined headers for differences, but the implementations are binary
compatible by design, making differences intentionally minimal.
I suppose one can grep the pthreads.h header for the following:
/* Linuxthreads - a simple clone()-based implementation of Posix */
/* threads for Linux. */
/* Copyright (C) 1996 Xavier Leroy (xavier.le...@inria.fr) */
Jeff,
Note that you *still* have an account on my old RHL 8.0 machine which
has LinuxThreads (and a 2.4.x kernel). Contact me offlist if you need
help getting back on it.)
-Paul
On 3/16/2011 3:30 AM, Jeff Squyres (jsquyres) wrote:
Is there a version in a pthreads header file that can be checked?
You're right that I am currently checking Linux kernel version, not pthread
version. Note that this is *only* in cross-compiling environments; in non cross
compiling situations, we actually test the behavior to see if threads have
different PIDs or not.
Sent from my phone. No type good.
On Mar 15, 2011, at 7:41 PM, "Ralph Castain"<r...@open-mpi.org> wrote:
My point was just that we support the current implementation of pthreads - not
any old one.
Also, to clarify: Jeff actually tests to see what the thread library does. We
only use the Linux kernel version when cross-compiling since we cannot, in that
case, actually test the support. We know that old Linux kernels have the old
implementation, so we exclude them. Anything else is hit-miss when
cross-compiling.
On Mar 15, 2011, at 4:46 PM, Paul H. Hargrove wrote:
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
_______________________________________________
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
_______________________________________________
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
