This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Wed, 18 Jun 2008, Terry Dontje wrote:
> Jeff Squyres wrote:
>> Perhaps we did that as a latency optimization...?
>> George / Brian / Galen -- do you guys know/remember why this was done?
>> On the surface, it looks like it would be ok to call progress and check
>> again to see if it found the match. Can anyone think of a deeper reason
>> not to?
> If it is ok to check again, my next question is going to be how? Because
> after looking at the code some more I found iprobe requests are not actually
> queued. So can I just do another MCA_PML_OB1_RECV_REQUEST_START on the
> init'd IPROBE_REQUEST after the call opal_progress to force a search on the
> unexpected queue or do I need to FINI the request and regenerate it again?
I think you'd have to re-init the request at a minimum. In other words,
just always call opal_progres at the top of iprobe and be done :).