George --

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

Brian


On 11/27/09 18:24 , "George Bosilca" <bosi...@eecs.utk.edu> wrote:

> Brian,
> 
> 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.
> 
>   Thanks,
>     george.
> 
> 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.
>> 
>> Brian
>> 
>> 
>> 
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 

--
   Brian W. Barrett
   Dept. 1423: Scalable System Software
   Sandia National Laboratories



Reply via email to