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.
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