On Nov 27, 2007, at 5:13 PM, Terry Frankcombe wrote:
==20671== Conditional jump or move depends on uninitialised value(s)
==20671==at 0x40152B1: (within /lib/ld-2.5.so)
==20671==by 0x400A289: (within /lib/ld-2.5.so)
==20671==by 0x6A42E4D: (within /lib/libc-2.5.so)
==20671==by 0x5
We've had a few users complain about trying to use THREAD_MULTIPLE
lately and having it not work.
Here's a proposal: why don't we disable it (at least in the 1.2
series)? Or, at the very least, put in a big stderr warning that is
displayed when THREAD_MULTIPLE is selected?
Comments?
--
On Wed, 28 Nov 2007, Jeff Squyres wrote:
We've had a few users complain about trying to use THREAD_MULTIPLE
lately and having it not work.
Here's a proposal: why don't we disable it (at least in the 1.2
series)? Or, at the very least, put in a big stderr warning that is
displayed when THREAD_M
Ya, the front page needs some updating...
On Nov 28, 2007, at 11:32 AM, Brian W. Barrett wrote:
On Wed, 28 Nov 2007, Jeff Squyres wrote:
We've had a few users complain about trying to use THREAD_MULTIPLE
lately and having it not work.
Here's a proposal: why don't we disable it (at least in t
Are there not users that are using THREAD_MULTIPLE successfully, or is this
on the trunk ? We know that the code is not where it needs to be, but if
this takes away current functionality, I would prefer to display a warning.
Rich
On 11/28/07 11:27 AM, "Jeff Squyres" wrote:
> We've had a few u
I haven't tried to debug the following but I am getting the following
errors when building the vt-integration tmp branch on Solaris. So I
don't think the branch is ready for putback yet.
--td
cc -DHAVE_CONFIG_H -I. -I..
-I/workspace/tdd/ct7/ompi-ws-vt/ompi-vt-integration/builds/ompi-vt-inte
The MPICH guys presented TCP results with THREAD_MULTIPLE at Euro PVM/
MPI and frankly, I was amazed that it worked at all.
I seriously doubt that we're going to advance the state of threading
on the 1.2 series (which is nowhere as close as it is on the 1.3
series).
On Nov 28, 2007, at 12
Jeff Squyres wrote:
The MPICH guys presented TCP results with THREAD_MULTIPLE at Euro PVM/
MPI and frankly, I was amazed that it worked at all.
I seriously doubt that we're going to advance the state of threading
on the 1.2 series (which is nowhere as close as it is on the 1.3
series).
There is a priority change for us. It's definitively time to have a
fully supported MPI_THREAD_MULTIPLE mode in Open MPI. I'm working to
figure out how and where to get the cycles for this. I expect to start
working on it in January. So, the good news is that 1.3 will have
thread support.
On Nov 28, 2007, at 1:26 PM, George Bosilca wrote:
There is a priority change for us.
"us" = UTK?
It's definitively time to have a fully supported MPI_THREAD_MULTIPLE
mode in Open MPI. I'm working to figure out how and where to get the
cycles for this. I expect to start working on it in J
Yes, "us" means UTK. Our math folks are pushing hard for this. I'll
gladly accept any help, even if it's only for testing. For
development, I dispose of some of my time and a 100% of a post-doc for
few months.
However, there are limits to what we can do. We will make sure the BTL
threadin
On Wed, Nov 28, 2007 at 01:46:53PM -0500, George Bosilca wrote:
> Yes, "us" means UTK. Our math folks are pushing hard for this. I'll gladly
> accept any help, even if it's only for testing. For development, I dispose
> of some of my time and a 100% of a post-doc for few months.
I already worked
If the guidelines are made for the BTLs Sun will handle the udapl btl.
We can also help in testing too.
--td
George Bosilca wrote:
Yes, "us" means UTK. Our math folks are pushing hard for this. I'll
gladly accept any help, even if it's only for testing. For
development, I dispose of some of
13 matches
Mail list logo
