al/mca/mca.h"
> #include "opal/mca/base/base.h"
> +#include "opal/mca/event/event.h"
>
> BEGIN_C_DECLS
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
--
Brian Barrett
There is an art . . . to flying. The knack lies in learning how to
throw yourself at the ground and miss.
Douglas Adams, 'The Hitchhikers Guide to the Galaxy'
complete, and I've got to keep working on my own features for v1.7.5, so
> I need to move to other things right now.
These start to sound like issues in the code; those last two are pretty decent
tests.
> I think I have oshmem running well enough to add these to Cisco's nightly M
On Jan 13, 2009, at 5:48 PM, Patrick Geoffray wrote:
Jeff Squyres wrote:
Gaah! I specifically asked Patrick and George about this and they
said that the README text was fine. Grr...
When I looked at that time, I vaguely remember that _both_ PMLs were
initialized but CM was eventually use
).
What Brian describe is the best compromise we manage to find few
months ago. If you want to get the MX CM to run, you will have to
clearly specify on the command line --mca pml cm. All other MTL will
have the behavior described on the README.
george.
On Jan 13, 2009, at 20:18 , Brian Barr
I unfortunately don't have time to look in depth at the patch. But my
concern is that currently (today, not at some made up time in the
future, maybe), we use the BTLs for more than just MPI point-to-
point. The rdma one-sided component (which was added for 1.3 and
hopefully will be the de
evel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
s is being done on a tmp branch only until everything is in
order I
think we need further discussions.
--td
Brian Barrett wrote:
So once again, I bring up my objection of this entire line of
moving
until such time as the entire process is properly mapped out. I
believe it's premature to
y D. Dontje" wrote:
I second Brian's concern. So unless this is just an announcement
that
this is being done on a tmp branch only until everything is in
order I
think we need further discussions.
--td
Brian Barrett wrote:
So once again, I bring up my objection of this entire line
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
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
I'd rather not. I have a couple of platforms with 2.59 installed, but
not 2.60+. I really don't want to have to install my own autotools
because of some bug that doesn't affect me.
I don't, however, have a problem with forcing users to upgrade in
order to get support for build-related iss
Jumping in late (travelling this morning). I think this is the right
answer :).
Brian
--
Brian Barrett
There is an art . . . to flying. The knack lies in learning how to
throw yourself at the ground and miss.
On May 8, 2009, at 9:45, Ralph Castain wrote:
I think that's the way to go
tever, to work around optimizer bugs. This is
functionality I don't think should be lost just to warn about
deprecated functions.
Brian
--
Brian Barrett
There is an art . . . to flying. The knack lies in learning how to
throw yourself at the ground and miss.
On May 18, 2009, at 1:
Yeah, putting together a CMR is on the todo list :).
Brian
--
Brian Barrett
There is an art . . . to flying. The knack lies in learning how to
throw yourself at the ground and miss.
On May 20, 2009, at 12:41, Jeff Squyres wrote:
Brian: can we CMR over your OSD changes from 30 Apr
Or go to what I proposed and USE A LINKED LIST! (as I said before,
not an original idea, but one I think has merit) Then you don't have
to size the fifo, because there isn't a fifo. Limit the number of
send fragments any one proc can allocate and the only place memory can
grow without bo
On Jun 30, 2009, at 5:57 PM, Ralph Castain wrote:
If you are updating a prior checkout of the OMPI trunk with r21568,
please be aware that there is an additional step required to make it
build. Due to a quirk of the build system, you will need to do:
rm ompi/tools/ompi_info/.deps/*
and the
-mpi.org/mailman/listinfo.cgi/devel
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
use orterun to launch normal old unix
commands. Something with a bit of stdio output will give a
reasonable first test of the oob. I usually do something like:
orterun -np 2 -host host_a,host_b ls -l $HOME
as I have enough files in my home directory that a page or two of
standard I/O shou
I'll admit it
has been a year or so since I've looked at this, so I could be
completely off base there.
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
On Mar 31, 2006, at 10:15 AM, Adrian Knoth wrote:
On Fri, Mar 31, 2006 at 09:36:31AM -0500, Jeff Squyres (jsquyres)
wrote:
I have no personal experience with IPv6, but one thought that
strikes me
is that the components might be able to figure out what to do by
looking
at/parsing either t
IPv6 support, but I could be wrong there.
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
On Apr 6, 2006, at 11:21 AM, Sushant Sharma wrote:
Just checked out fresh trunk and got this error.
In file included from ../../ompi-trunk/opal/runtime/opal_finalize.c:
33:
../../ompi-trunk/opal/mca/memcpy/base/base.h:72:44:
opal/mca/memcpy/base/base_impl.h: No such file or directory
make[2]:
ly do the
standard LP64 setup. So no worries there.
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
affect the v1.1 release in any way, but
thought I would mention it here.
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
.
During this time, checkouts, updates, and checkins will not function
properly.
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
bably give a better idea of exactly what
is happening...
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
Are these both identical architecture? Those look suspiciously like
what happens when you're trying to mix 32/64 bit or little endian /
big endian.
Brian
On Apr 20, 2006, at 8:53 PM, Galen M. Shipman wrote:
Hey Guys,
Not sure what is going on here, has anyone seen this before?
- Galen
I'm just
kind of guessing as to how one could get to that situation...
Brian
On Apr 21, 2006, at 5:01 PM, Manjunath G Venkata wrote:
On Thu, 20 Apr 2006, Brian Barrett wrote:
Are these both identical architecture? Those look suspiciously
like what happens when you're trying to
Hi all -
We're going to lose all Open MPI resources hosted at IU (which is
pretty much everything) on Saturday, May 13th. We don't have much we
can do about this, as the university is cutting our power. So a
Saturday off from development :).
Brian
Begin forwarded message:
From: DongI
rse,
you might want to start with something dead simple, like NetPIPE, and
work your way up ;).
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
Probably means this was a problem in some ancient version of our
environment and it never got changed. It looks reasonable, so I'll
make it so. Which platforms will barf with the './config'? Trying
to figure out which branches this needs to be committed to...
Thanks,
Brian
On May 6, 20
. I'll let you know when the fixes become
available
Thanks,
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
On May 8, 2006, at 1:54 PM, Ralf Wildenhues wrote:
Hi Brian, Dries,
* Brian Barrett wrote on Mon, May 08, 2006 at 01:43:38PM CEST:
However, we really *should* abort configure and warn the user if --
enable-io-romio is given and ROMIO fails to configure. I will fix
this with the LDFLAGS fix
tch to our
development trunk. It should be in tomorrow morning's nightly
tarball for any of the active release branches (the trunk, v1.0, and
v1.1):
http://www.open-mpi.org/nightly/
Thanks again,
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
previously stored value:
Thanks for finding this one as well. A fix will be in tonight's
nightly tarballs.
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
I think I have this fixed (using the $file_system_[foo] variables).
Thanks for all the bug reports. I've committed to the trunk and am
building a new nightly tarball right now. Can you try it to make
sure I have all your issues fixed?
Thanks for all the bug reports!
Brian
On May 8, 200
)
libadio_la_DEPENDENCIES = \
$(libadio_la_LIBADD)
Greetings,
Dries
PS. This should be the last one, I finally have the combo Open MPI,
ROMIO & PVFS2 over native IB up and running :-)
Thanks. Fixed on the trunk, and hopefully moving into the release
branches soon.
Brian
--
Brian Bar
Eeeks! That sounds like a bug. Can you attach a debugger and get a
stack trace for the situation where that occurs?
Brian
On May 10, 2006, at 10:17 PM, Rolf Vandevaart wrote:
I have built a library with "--enable-mpi-threads --with-
threads=posix"
(using
the trunk) and tried running a s
Hi all -
Due to our building losing power tomorrow, all OSL-provided services
will be unavailable for the day. Since that's just about everything
@open-mpi.org, just about everything will be down tomorrow.
I apologize for the downtime - there is a new building going up next
to ours and t
nassigned bugs. For now,
plan on receiving e-mails about unassigned bugs on Mondays and then
hearing about them on the weekly telecon ;). Please let me know if
you have any questions about the bug tracker.
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
As always, Thanks! Committed and hopefully moving to 1.1, as I'd
like to eventually bootstap that branch with 2.60.
Brian
On May 30, 2006, at 9:51 AM, Ralf Wildenhues wrote:
The following patches fix two rather nasty issues with configury, and
one missing bit of GCS update. All changes sho
more
than one process per processor.
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
MPI_GET function, a stack trace and
sample application would be most useful.
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
On Mon, 2006-07-10 at 17:44 +0200, Pierre wrote:
> rtsig.c:365: error: `EV_SIGNAL' undeclared (first use in this function)
> rtsig.c:392: error: dereferencing pointer to incomplete type
> rtsig.c:392: error: `EV_PERSIST' undeclared (first use in this function)
> make[3]: *** [rtsig.lo] Error 1
> m
Hi all -
I just finished committing the event library into the trunk.
Unfortunately, because the event library was not imported using a
vendor import 2 years ago, I had to do some things that made SVN a
little unhappy. The good news is that the next libevent update will
not require thes
On Thu, 2006-07-27 at 15:21 -0700, Ben Byer wrote:
> I'd like to be able to build OpenMPI "fat" -- for multiple
> architectures in one pass, so I can create a universal binary for
> OSX. I see that it was mentioned last year, at http://www.open-
> mpi.org/community/lists/users/2005/06/0087.ph
On Thu, 2006-07-27 at 07:49 -0400, Graham E Fagg wrote:
> Hi all
> is there a single function call that components can use to check that the
> progress thread is up and running ?
Not really. But if the define OMPI_ENABLE_PROGRESS_THREADS is 1 and
opal_using_threads() returns true, then it can
Hi all -
Two large changes to the SVN trunk just occurred which require an
autogen.sh on your part. First, we now (mostly) support building the
Fortran 90 MPI bindings library as a shared library. This has been
something Dan and I have been working on since the Burlington meeting,
and it's ready
On Thu, 2006-07-20 at 11:56 +1000, gh rory wrote:
> In the process of trying to create a wrapper for open mpi to another
> language. Specifically, I am trying to understand how the remote
> memory access/one-sided communication works in open mpi 1.1, and I am
> having some trouble.
>
> I have
Hello all -
The release branch for the v1.2 release of Open MPI was created this
afternoon. The branch was created from r11198 of the trunk. A couple
of minor changes have been made to the v1.2 branch that did not go
through the ordinary branch release process:
* remove btl:ud and pls:xcpu co
On Mon, 2006-08-21 at 09:38 +0200, Ralf Wildenhues wrote:
> Revision 11268 makes me curious:
>
> |M /trunk/config/ompi_setup_cxx.m4
> |
> | Reorder the C++ compiler discovery stages. Check first the compiler vendor
> | before checking if we are able to compile the test program. This is requir
Hi all -
LANL had an internal meeting yesterday trying to classify a number of
issues we're having with the run-time environment for Open MPI and how
to best prioritize team resources. We thought it would be good to
both share the list (with priorities) with the group and to ask the
group if ther
In general, I think making the Public interface to OpenRTE not thread
safe is a reasonable thing to do. However, I have some concern over how
this would work with the event library. When the project is compiled
with progress threads, the event library runs in its own thread. More
important to th
Hi all-
A question about stack tracing. Currently, we have it setup so that,
say, a segfault results in:
[0]func:/u/jjhursey/local/odin/ompi/devel/lib/libopal.so.0(opal_backtrace_print+0x2b)
[0x2a959166ab]
[1] func:/u/jjhursey/local/odin/ompi/devel/lib/libopal.so.0 [0x2a959150bb]
[2] func:/lib6
Yes. It's always the trampoline, the signal handler, and the stack
trace printer.
Brian
On Wed, 2006-08-30 at 17:37 -0400, Jeff Squyres wrote:
> As long as it's always 3 function calls -- do we know that it will be?
>
>
> On 8/30/06 5:32 PM, "Brian Barrett"
What facilities are you using to detect the buffer overflow? We've seen
no such issues in our testing and I'd be surprised if there was an issue
in that code path. Valgrind and friends don't show any issues on our
test machines, so without more detail, I'm afraid we really can't fix
the issue you
On Tue, 2006-09-05 at 12:07 -0700, Ben Byer wrote:
> Hi all! I'm happy to report that I was able to build OpenMPI 1.1 4-
> way fat (ppc, i386, ppc64, x86_64) using buildpackage.sh.
>
> When I installed the resulting package, it installed the following
> include files:
>
> /usr/include/constan
I ran into a situation (I don't remember the exact details,
unfortunately), where the C compiler supports asprintf() but the C++
compiler doesn't. I believe this came up when I was compiling with
gcc (C) and xlC (C++). But it might have been another set of
compilers -- I unfortunately don
ll no longer occur.
Brian
On Thu, 2006-08-31 at 15:56 -0600, Brian Barrett wrote:
> What facilities are you using to detect the buffer overflow? We've seen
> no such issues in our testing and I'd be surprised if there was an issue
> in that code path. Valgrind and friends don&
Because I'm silly. I shall make it so - Thanks!
Brian
On Oct 13, 2006, at 5:44 AM, Ralf Wildenhues wrote:
Hello Brian, all,
| r12094 | brbarret | 2006-10-11 20:40:21 +0200 (Wed, 11 Oct 2006)
| 11 lines
| Changed paths:
|M /trunk/opal/util/output.c
|
| Use write() instead of fprintf()
Hi all -
At the last minute last night I wanted to change one small detail in
the wrapper compiler code. Then, as is typical with me, I got
distracted. As some of you noticed, none of the configure changes
made it into the trunk last night. Should happen this weekend.
Sorry about that
Adrian -
I just committed some code in the TCP OOB component to deal with
packing / unpacking sockaddr_in structures for cases where there is
different heterogeneity / padding. I think it's going to require
some work to make it IPv6 friendly. Just an FYI.
Brian
On Oct 16, 2006, at 5:0
per data files to piece together to activate the multi-lib
support in the wrapper compilers.
Comments?
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
On Feb 15, 2007, at 3:07 AM, Bert Wesarg wrote:
I encounter a build problem with openmpi 1.1.4, which don't show up
with
version 1.1.2.
After a simple ./configure, the variable OPAL_DATADIR in
opal/include/opal/install_dirs.h shows this:
$ grep '^#define OPAL_DATADIR' openmpi-1.1.2/opal/incl
On Feb 15, 2007, at 2:54 AM, Bert Wesarg wrote:
why are the mpiCC, mpif77, and mpif90 wrappers installed, when i
specify
--disable-mpi-cxx, --disable-mpi-f77, and --disable-mpi-f90 for the
./configure?
The Fortran 77 and Fortran 90 compilers will be disabled and return
an error if those la
Very true, thanks. I'll fix this evening.
Brian
On Feb 25, 2007, at 4:51 AM, Bert Wesarg wrote:
Hallo,
ok the sed should be even more portable. but the problem with a CC
like
"gcc -m32" isn't solved, so you should add this line and use the
$tmpCC
in the sed expression, to get "gcc -m32
On Feb 26, 2007, at 1:54 PM, Bert Wesarg wrote:
I can only speak for a 3 year old linux system but I read evenly
the wiki
page https://svn.open-mpi.org/trac/ompi/wiki/PrintfCodes and I
wonder if
someone tried this code. On my system the PRId32 is defined as "d" for
example. so to use this yo
.
Than you.
Bert Wesarg
Brian Barrett wrote:
Very true, thanks. I'll fix this evening.
Brian
On Feb 25, 2007, at 4:51 AM, Bert Wesarg wrote:
Hallo,
ok the sed should be even more portable. but the problem with a CC
like
"gcc -m32" isn't solved, so you should add this lin
On Apr 2, 2007, at 10:23 AM, Jeff Squyres wrote:
On Apr 1, 2007, at 3:12 PM, Ralph Castain wrote:
I can't help you with the BTL question. On the others:
2. Go through the BML instead -- the BTL Management Layer. This is
essentially a multiplexor for all the BTLs that have been
instantiated.
Well, that eliminates the easy ones. MPI_Cartdim_get isn't one of
the more popular functions, so it's probably a bug in there. Would
it be possible to get access to the code?
Thanks,
Brian
On Apr 11, 2007, at 4:20 PM, Paul Weber wrote:
David,
Here's some more info. Looks like he is u
Wow, it appears everything aborts when opal_event_loop() is called.
Did you make any changes to the event library code in opal/event/?
If not, that might indicate a mismatch between the binaries and
libraries (ie, binaries from one build vs. libraries from another).
This will cause rando
On Apr 19, 2007, at 8:38 AM, Aurelien Bouteiller wrote:
Hi,
I am experiencing several fancy bugs with ORTE.
All bugs occur on Intel 32 bits architecture under Mac OS X using gcc
4.2. The tested version is todays trunk (it also have occured for at
least three weeks)
First occurs when compiling
Hi all -
As was discussed on the telecon a couple of weeks ago, to try to
lower the maintenance cost of the build system, starting this
Saturday Autoconf 2.60 and Automake 1.10 will be required to
successfully run autogen.sh on the trunk. As I mentioned in a
previous e-mail, the required
Hi all -
After a minor hiccup last night, nightly tarballs for the trunk (and
eventually v1.3 branch) are now made with AC 2.61, AM 1.10, and LT
2.1a. Don't forget the mandatory update of AC and AM for the trunk
coming saturday morning!
Brian
On May 8, 2007, at 2:03 PM, Brian Barrett wrote:
As was discussed on the telecon a couple of weeks ago, to try to
lower the maintenance cost of the build system, starting this
Saturday Autoconf 2.60 and Automake 1.10 will be required to
successfully run autogen.sh on the trunk. As I
On the other hand, since the MPI standard explicitly says you're not
allowed to call fork() or system() during the MPI application and
sense the network should really cope with this in some way, if it
further complicates the code *at all*, I'm strongly against it.
Especially since it won't
On May 28, 2007, at 10:59 AM, Jack Howarth wrote:
On MacOS X, the current v1.1.5 and v1.2.2 sources for openmpi
create shared libraries with undefined environ symbols. This
problem on MacOS X and the available workarounds are discussed
on the fink wiki section on Porting Notes...
I understa
On May 28, 2007, at 4:57 PM, Jack Howarth wrote:
I have been told that Paraview is one package that
exhibits this problem with undefined environ symbols.
This will occur in any package which creates its own
shared libraries that link in any openmpi shared library
that contains the undefined e
On May 29, 2007, at 7:35 AM, Jack Howarth wrote:
and if you see environ undefined, identify which library
it is in and which object file it came from. I would also
note that my patch reveals that several instances of the
environ variable being declared that are missing the Windows
wrappers. So i
Yup, thanks.
Brian
On Jun 6, 2007, at 2:27 AM, Bert Wesarg wrote:
+#ifdef HAVE_REGEXEC
+args_count = opal_argv_count(options_data[i].compiler_args);
+for (j = 0 ; j < args_count ; ++j) {
+if (0 != regcomp(&res, options_data[i].compiler_args
[j], REG_NOSUB)) {
+
I'm available this afternoon...
Brian
On Jun 7, 2007, at 12:39 PM, George Bosilca wrote:
I'm available this afternoon.
george.
On Jun 7, 2007, at 2:35 PM, Galen Shipman wrote:
Are people available today to discuss this over the phone?
- Galen
On Jun 7, 2007, at 11:28 AM, Gleb Natapo
Yes, this is a known issue. I don't know -- are we trying to make
threads work on the 1.2 branch, or just the trunk? I had thought
just the trunk?
Brian
On Jun 11, 2007, at 8:13 AM, Tim Prins wrote:
I had similar problems on the trunk, which was fixed by Brian with
r14877.
Perhaps 1.
Argonne used AC_TRY_RUN instead of AC_TRY_COMPILE (I believe) because
there are some places where aio functions behaved badly (returned
ENOTIMPL or something). I was going to make it call AC_TRY_RUN if we
weren't cross-compiling and AC_TRY_COMPILE if we were. I'll commit
something this ev
On Jun 19, 2007, at 8:35 AM, Terry D. Dontje wrote:
Rainer Keller wrote:
Hello dear all,
with the current numbering in mpif-common.h, the optional ddt
MPI_REAL2 will
break the binary compatibility of the fortran interface from v1.2 to
v1.3
(see r15133).
Now apart from MPI_REAL2 being of let's
Following up on the telecon conversation about automatically forcing
components to build statically (ie, part of libmpi and friends
instead of a stand-alone dso), here's an example of how to do so:
AC_DEFUN([MCA_backtrace_darwin_COMPILE_MODE], [
AC_MSG_CHECKING([for MCA component $2:$3 c
On Jun 26, 2007, at 6:08 PM, Tim Prins wrote:
Some time ago you were working on moving the modex out of the pml
and cleaning
it up a bit. Is this work still ongoing? The reason I ask is that I am
currently working on integrating the RSL, and would rather build on
the new
code rather than th
ng as long as we can have some sort of
documenation describing what changed like which old functions
are replaced with newer functions and any description of changed
assumptions.
--td
Brian Barrett wrote:
On Jun 26, 2007, at 6:08 PM, Tim Prins wrote:
Some time ago you were working on movin
On Jul 5, 2007, at 4:16 PM, Glendenning, Lisa wrote:
Ron Brightwell at SNL has asked me to look into optimizing Open MPI's
one-sided operations over Portals. Does anyone have any guidance or
thoughts for this?
Hi Lisa -
There are currently two implementations of the one-sided interface
for
Hi all -
I've finally committed a version of the rdma one-sided component that
1) works and 2) in certain situations actually does rdma. I'll make
it the default when the BTLs are used as soon as one last bug is
fixed in the DDT engine.
However, there is still one outstanding issue. Som
On Jul 10, 2007, at 7:09 AM, Tim Prins wrote:
Jeff Squyres wrote:
2. The "--enable-mca-no-build" option takes a comma-delimited list of
components that will then not be built. Granted, this option isn't
exactly intuitive, but it was the best that we could think of at the
time to present a gene
Do you have a Subversion account? If so, feel free to update the
wiki ;). If not, we should probably get you an account. Then feel
free to update the wiki ;). But thanks for the notes!
Brian
On Jul 11, 2007, at 4:47 PM, Glendenning, Lisa wrote:
Some supplementary information to the wik
On Jul 11, 2007, at 4:47 PM, Glendenning, Lisa wrote:
* When linking with libopen-pal, the following warning is normal:
'In
function `checkpoint_response': warning: mkfifo is not implemented and
will always fail'
Josh -
I thought the checkpoint code wasn't built unless requested. Anyway,
On Jul 14, 2007, at 8:26 AM, Dirk Eddelbuettel wrote:
Please let us (ie Debian's openmpi maintainers) how else we can
help. I am
ccing the porters lists (for hppa, m68k, mips) too to invite them
to help. I
hope that doesn't get the spam filters going... I may contact the
'arm'
porters onc
On Jul 14, 2007, at 10:53 AM, Dirk Eddelbuettel wrote:
Methinks we need to fill in a few blanks here, or make do with non-asm
solutions. I don't know the problem space that well (being a
maintainer
rather than upstream developer) and am looking for guidance.
Either way is an option. There
On Jul 14, 2007, at 11:16 AM, George Bosilca wrote:
Instead of failing at configure time, we might want to disable the
threading features and the shared memory device if we detect that we
don't have support for atomics on a specified platform. In a non
threaded build, the shared memory device is
On Jul 14, 2007, at 11:51 AM, Gleb Natapov wrote:
On Sat, Jul 14, 2007 at 01:16:42PM -0400, George Bosilca wrote:
Instead of failing at configure time, we might want to disable the
threading features and the shared memory device if we detect that we
don't have support for atomics on a specified
penib (completely or partially?)
Anybody knows about any other components with atomic requirements ?
george.
On Jul 14, 2007, at 1:59 PM, Brian Barrett wrote:
On Jul 14, 2007, at 11:51 AM, Gleb Natapov wrote:
On Sat, Jul 14, 2007 at 01:16:42PM -0400, George Bosilca wrote:
Instead of faili
Hey all -
Thought I would give you guys a heads up on some code that will be
coming into the trunk in the not too distant future (hopefully
tomorrow?). The changes revolve around the RML/OOB interface and
include:
* General TCP cleanup for OPAL / ORTE
* Simplifying the OOB by moving
Sigh. Thanks. Should probably have tested that code ;). And the
solaris code. and the windows code.
Brian
On Jul 19, 2007, at 7:37 AM, Jeff Squyres wrote:
Thanks!
Ralph got it this morning in https://svn.open-mpi.org/trac/ompi/
changeset/15501.
On Jul 19, 2007, at 5:34 AM, Bert Wesarg
On Jul 24, 2007, at 8:28 AM, Gleb Natapov wrote:
On Tue, Jul 24, 2007 at 11:20:11AM -0300, Lisandro Dalcin wrote:
On 7/23/07, Jeff Squyres wrote:
Does anyone have any opinions on this? If not, I'll go implement
option #1.
Sorry, Jeff... just reading this. I think your option #1 is the
bett
I have an even bigger objection than Rich. It's near impossible to
measure the latency impact of something like this, but it does have
an additive effect. It doesn't make sense to have all that code in
the critical path for systems where it's not needed. We should leave
the compile time
1 - 100 of 238 matches
Mail list logo
