On Wed, Mar 13, 2013 at 03:09:22PM -0500, William Gropp wrote:
Relevant to this is that enhancing generalized requests also came up. Part of the discussion is this: would an enhancement to generalized requests, which would have broader benefit, be a more general solution?
Background: The Forum is increasingly concerned about the creation of routines to solve specific problems rather than stepping back and trying to find a more general and powerful solution.
With the disclaimer that I am not a Forum participant... "rule of three" is a nice guideline for the specific/general approach. Find three use cases and now you've properly motivated taking the time to design a general solution. We have "rule of one" right now. The only grequest client is I/O. The only extended grequest client is I/O. Torsten's nonblocking collectives could have been case number two. He found standard grequests unworkable and apparently found it easer to advocate for nonblocking collectives via the forum than to adopt and advocate for extended grequests. I'd say delete or deprecate grequests if one is concerned with API bloat to make room for non-blocking I/O routines! In 15 years there has been but one paper examining grequests (ours). There has been but one grequest client -- ROMIO (ours) -- and that only because ROMIO was implemented as a stunt: implement the MPI-IO chapter on top of (instead of integrated into) an MPI-1 implementation. Said differently: improve grequests and MPI will still likely have zero grequest consumers. improve I/O and MPI will have at the very least HDF5 as a customer. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA