Sure. Since I had talked to you and Jeff about it a year ago (when you
added the callback) and you didn't complain, I assumed you two would be the
only ones to care and wouldn't complain this time. Guess I should have
known better :).
On 11/27/09 18:24 , "George Bosilca" <bosilca_at_[hidden]> wrote:
> This is a pretty big change to be done with a so short notice, especially over
> the Thanksgiving weekend. I do have a lots of concerns about this approach,
> but I lack the time to expand on this right now. I'll be back at work on
> Monday and I'll give detailed informations. Please delay the deadline until at
> least Wednesday.
> On Nov 25, 2009, at 11:52 , Barrett, Brian W wrote:
>> WHAT: Add a void* extra_state field to ompi_request_t
>> WHY: When we added the req_complete_cb field so that internal pieces of OMPI
>> who generated requests (such as the OSC components using the PML) could be
>> async notified when the request completed (ie, the PML request the OSC
>> component had initiated was finished), we neglected to add any type of
>> "extra state" associated with that request/callback. So the completion
>> callback is almost worthless, because the upper layer has a hard time
>> figuring out which thing it was working on it can now progress due to the
>> given (lower?) request completing.
>> WHERE: One line in each of ompi/request/request.[hc].
>> WHEN: ASAP
>> TIMEOUT: Sunday, Nov 29.
>> More Details
>> This is probably not even worth an RFC, which is why I'm not giving a very
>> long timeout (that, and if I don't get this done during the holiday weekend,
>> it will never get done). The changes are a single line in request.h adding
>> a void* extra_state variable to the ompi_request_t and another single line
>> in request.c to initialize the field to NULL.
>> While looking for some other code, I stumbled upon the OSC changes I made a
>> long time ago to try to use req_complete_cb instead of registering a
>> progress function. The code is actually a lot cleaner that way, and means
>> no progress functions for the one-side components.
>> The down side is that it adds another 8 bytes to ompi_request_t, which is
>> already larger than I'd like. But on the flip side, we have an 8 byte field
>> (the callback) which is totally unusable without the extra_state field.
>> devel mailing list
> devel mailing list
Brian W. Barrett
Dept. 1423: Scalable System Software
Sandia National Laboratories