(j3.2006) [MPI3 Fortran] Feedback from Fortran J3 meeting

Van Snyder Van.Snyder
Fri May 30 15:46:35 EDT 2008


On Fri, 2008-05-30 at 08:12 -0600, Keith Bierman wrote:
> On May 30, 2008, at 6:04 AM   5/30/, Toon Moene wrote:
> 
> > Van Snyder wrote:
> >
> >> Keith remarked that many vendors had worked very hard to prevent  
> >> users
> >> from intercepting I/O.
> 
> 
> I must confess I don't recall making that assertion, or the context  
> it might have been made in.

It was at the February 1997 meeting at the Sunrise Suites, at which I
proposed to allow user hooks into the I/O process in paper 97-114.  I
gave several reasons for wanting to allow users to process I/O at the
lowest level, including MPI/PVM.

> I/O tends to be pretty slow; on the other hand exposing the inner  
> workings of the I/O library is often an exercise in pain (and might  
> constrain future internal evolution).

My proposal was perhaps naively colored by my knowledge of the simple
method used by the Univac Fortran V compiler, which had only three
entries into the Fortran I/O library: Start, "Process another object",
Finish.  Start provided the unit number, the format if any, and whether
it was a read or write.  "Process another object" provided the address
and extent of an object (contiguous, IIRC).  Finish finished.  I don't
remember whether namelist was processed entirely differently.

For purposes of the present discussion, it could be limited to
unformatted I/O, or described in a form that makes it clear that user
code doesn't get hooked until after format processing.  The "Process
another object" piece would benefit from a void* argument mechanism.

I can imagine this being done by providing an object of a nonabstract
extention of one of two standard-defined abstract base types (read,
write) having three deferred type-bound procedures (start, continue,
finish) to OPEN.  Maybe the "continue" procedure should be generic for
ranks at least zero and one, or perhaps impure elemental.

> So I suspect I might have discouraged it; but not for performance  
> reasons.





More information about the J3 mailing list