Did this ever get fixed? Anyone able to do so (I can't - no access to PGI or
environment)?
On Sep 29, 2010, at 1:45 PM, Aurélien Bouteiller wrote:
> Here is the problem. The PGI compiler is especially paranoid regarding post
> declared structures typedefs. It looks like the include ordering ma
On Oct 25, 2010, at 9:29 PM, George Bosilca wrote:
> 1. Not all processes deadlock in btl_sm_add_procs. The process that setup the
> shared memory area, is going forward, and block later in a barrier.
Yes, I'm seeing the same thing (I didn't include all details like this in my
post, sorry). I w
Btw it strikes me that we could put the old libevent back as a separate
component for comparisons.
Sent from my PDA. No type good.
On Oct 26, 2010, at 6:20 AM, "Jeff Squyres" wrote:
> On Oct 25, 2010, at 9:29 PM, George Bosilca wrote:
>
>> 1. Not all processes deadlock in btl_sm_add_procs.
Hi all,
This problem may be a detail, but it bugs me a lot, so I'd like to have it
fixed. Here is a patch that changes the path setting algorithm to "last
component wins" instead of "first component wins".
This is as wrong as was the original code, except that it is
consistent with the way a
On Oct 26, 2010, at 6:55 AM, Sylvain Jeaugey wrote:
> This problem may be a detail, but it bugs me a lot, so I'd like to have it
> fixed.
Fair enough. :-)
> Here is a patch that changes the path setting algorithm to "last component
> wins" instead of "first component wins".
>
> This is as wr
On Tue, 26 Oct 2010, Jeff Squyres wrote:
I don't think this is the right way to fix it. Sorry! :-(
I don't think it is the right way to do it either :-)
I say this because it worked somewhat by luck before, and now it's
broken. If we put in another "it'll work because of a side effect of a
I'll take a look at fixing this the right way today.
Since I wrote both the original autogen.sh that guaranteed static-components
was ordered and PREFIX code, I had considered it to be a documented feature
that there was strong otdering in the static-components list. So personally,
I'd conside
I like the idea of putting the old libevent back as a separate component, just
for performance/correctness comparisons. I think it would be good for the
trunk, but for the release branches just choose one version to ship (so we
don't confuse users).
-- Josh
On Oct 26, 2010, at 6:27 AM, Jeff Sq
There are fundamental differences between the two event engines. Just as an
example the new one allow us to have multiple pools of sockets, making a lot
easier to implement optimized asynchronous operations using multiple threads.
If we add the old engine back, we will either have to implement t
On Oct 26, 2010, at 11:21 AM, George Bosilca wrote:
> There are fundamental differences between the two event engines. Just as an
> example the new one allow us to have multiple pools of sockets, making a lot
> easier to implement optimized asynchronous operations using multiple threads.
> If
On the teleconf today, two important topics were discussed about the 1.5.x
series:
-
1. I outlined my plan for a "small" 1.5.1 release. It is intended to fix a
small number of compilation and portability issues. Everyone seemed to think
that this was an ok idea. I have done some tomfool
On Oct 26, 2010, at 1:27 PM, Ralph Castain wrote:
> I think we can do the old libevent for now as the trunk doesn't exploit the
> new 2.0 features yet (though I have some implemented in a branch that is now
> on hold). However, if we can fix shared memory quickly (and Sam appears to
> have some
On Oct 26, 2010, at 3:07 PM, Jeff Squyres wrote:
> There seem to be 3 obvious options about moving forward (all assume that we
> do 1.5.1 as described above):
>
> A. End the 1.5 line (i.e., work towards transitioning it to 1.6), and then
> re-branch the trunk to be v1.7.
> B. Sync the trunk
13 matches
Mail list logo
