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