On Jun 14, 2005, at 10:45 AM, Andre Merzky wrote:
readv is more posix like, and more generic. It always works if you are on read level (e.g. HDF5 VFD layer ;-).
eread is more powerful: it allows applicatoin specific optimization which is not achievable with readv (the size of the iovecs in the read request is double of the size of the data returned!).
OK, I think we have both arrived at the same overall conclusion. I think eRead would be useful as a way to package an underlying complex service for implementing remote data requests. One must be able to extend the services on both the client and the server side to provide new e-modes to the user that implement these services. The vector read ops (not necessarily readv/pread, but perhaps something similar that describes patterned reads in a compact form, would be useful for other application use cases where we are are not permitted (or have no desire) touch or extend the remote service. I think readv/pread is a bit *too* restrictive, but we should have some similarly compact set of read ops that allow for gather/scatter type remote operations that do not require the service be installed on both ends (eg. just client side) in addition to an eRead() interface for access to two-sided services. So I guess we have a need to do both. For a suitable vread alternative, it would be useful to have something like read_pattern(descriptor,buffer,int nlogicaldims,int logicaldims[],offset[],block[],stride[]); to specify a patterned operation. The list of iovecs[] can be used for gather operations that cannot be encoded as a regular pattern. -john