Terry Dontje wrote:
Iain Bason wrote:
On Mar 3, 2010, at 3:04 PM, Jeff Squyres wrote:
Mmmm... good point. I was thinking specifically of the
if_in|exclude behavior in the openib BTL. That uses strcmp, not
strncmp. Here's a complete list:
ompi_info --param all all --parsable | grep incl
Iain Bason wrote:
On Mar 3, 2010, at 3:04 PM, Jeff Squyres wrote:
Mmmm... good point. I was thinking specifically of the if_in|exclude behavior
in the openib BTL. That uses strcmp, not strncmp. Here's a complete list:
ompi_info --param all all --parsable | grep include | grep :value:
mc
On Mar 3, 2010, at 3:26 PM, George Bosilca wrote:
> I guess this is the result different developers with different ideas working
> on a non consistent way. This is without talking about the fact that we do
> the same checking in several places, and we duplicate the code in a way that
> doesn't
On Mar 3, 2010, at 15:04 , Jeff Squyres wrote:
> On Mar 3, 2010, at 2:06 PM, Iain Bason wrote:
>
>>> 1. The individual entries now behave like pseudo-regexp's rather that
>>> strict matching. We used strict matching before this for a reason. If we
>>> want to allow regexp-like behavior, then
On Mar 3, 2010, at 3:04 PM, Jeff Squyres wrote:
>
> Mmmm... good point. I was thinking specifically of the if_in|exclude
> behavior in the openib BTL. That uses strcmp, not strncmp. Here's a
> complete list:
>
> ompi_info --param all all --parsable | grep include | grep :value:
> mca:opal:
On Mar 3, 2010, at 2:06 PM, Iain Bason wrote:
> > 1. The individual entries now behave like pseudo-regexp's rather that
> > strict matching. We used strict matching before this for a reason. If we
> > want to allow regexp-like behavior, then I think we should enable that with
> > special char
On Mar 3, 2010, at 1:24 PM, Jeff Squyres wrote:
> I'm not sure I agree with change #1. I understand in principle why the
> change was made, but I'm uncomfortable with:
>
> 1. The individual entries now behave like pseudo-regexp's rather that strict
> matching. We used strict matching before
I'm not sure I agree with change #1. I understand in principle why the change
was made, but I'm uncomfortable with:
1. The individual entries now behave like pseudo-regexp's rather that strict
matching. We used strict matching before this for a reason. If we want to
allow regexp-like behavio
I did test the patch 2 version and that does seem to be working for me.
However, that obviously doesn't mean that it's safe.
Should we put some atomics in there, to be absolutely sure? Or put a lock
around the dlsym code to ensure that only 1 thread calls dlsym?
-jms
Sent from my PDA. No typ
