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 Thu, 26 Jun 2008, Jeff Squyres wrote:
> On Jun 26, 2008, at 3:08 PM, George Bosilca wrote:
>> Here is the solution I propose. If you think there is any problem with it,
>> please let me know asap.
>> Move the progress function from the BML layer back into the PML. Then the
>> PML will have a way to check on it's pending requests, and progress them
>> accordingly. This solution offer the same number of function calls as what
>> we have today, and should only minimally affect the performances (one more
>> if in the progress function).
> Note that this would *not* force a progress function to exist in cm -- which
> (IIRC) was one of the reasons that the PML progress function was removed.
> The way George described it to me, the pml base would check for != NULL
> before registering it.
In that case, why not just have OB1 directly register the function (and
not change the PML interface at all)? The whole BML progress thing only
exists because opal_progress wasn't nearly as robust when we started as it
is today. Really, the BML and BTL interfaces shouldn't have progress
functions either and should just register directly with opal_progress, but
that's a different story for another time.