Re: Question(s) about recursive I/O in f2003

James Giles wrote:

(snip)

Well, first of all the term is a misnomer. There is no actual
recursion involved. Consider the following write statement:

Write(io_unit(p)) f(x)

Well, reentrant is closely related to recursive. It is
reentrant in the sense that the routine is entered again
before the previous I/O statement has completed.

And suppose IO_UNIT is a function. Suppose further that
there's I/O done within that function. Well, you might think
that the normal way to do this is to call the IO_UNIT function
before you call the I/O library to process the WRITE. And,
you could do that too, but many implementations don't (I'll
talk about what they actually do below).

I believe it is fairly common for the unit to be specified
in the initial call, and reasonably likely the format, too.
As far as I know, the standard doesn't require it.

And suppose that F is a function that also does I/O. Again,
you might think the proper thing to do is call F first and then
call the I/O library to process the WRITE. Again, implementations
could do that, but most don't.

What most implementations do when they process an I/O
statement is begin a sequence of calls to the I/O library.
The first initializes the process: prepares the library for the
type of I/O you're about to do (in this case, unformatted
write). The last step is to finalize the I/O process (which
might actually send any data buffered within the library
itself to the system - no, it's not what FLUSH does - and
maybe even return such internal buffers to the memory
manager). In between, there are several calls to the I/O
library that pass information to be processed next. There
might be a separate call for the unit number, for the format
(in this case, there isn't one, but for formatted I/O there
would be), and a separate call for each I/O list item. Etc.

As far as I know, it is the list items that are usually
the problem.

So, each I/O statement actually turns into a whole sequence
of procedure calls. And the function references we discussed
above might be made in between some of these I/O calls.
(snip)

Now, why would an implementation do things like that?
Well consider:

Write(11) (F(i), i = 1, max), (G(j), j = 1, max), ...

Where MAX is some large number. In order to precompute
the whole I/O list before beginning the I/O sequence you have
to make room for huge numbers of temporary values. It's
easier nowdays. But when the usual I/O imlementation
style was invented memory was not so cheap or abundant.
Even so, suppose that F is an array valued function: it could
still add up to a prohibitive amount of memory. By processing
the I/O list incrementally you avoid the need for large amounts
of such temporary storage.

I do remember when the OS/360 Fortran library was changed to
allow an array or implied do as one call, instead of one per
array element. The new library was backward compatible, but
new code was not compatible with the old library.

Note: few I/O implementations don't precompute the I/O control
list items (the stuff in the parenthesis after the statement keyword).
So, "recursive I/O" is probably safe there. But, I see no mention
of it either way in the standard document. Maybe I'm looking in the
wrong places.

As far as I know, not, but I don't know where it says it, either.

-- glen

.

Relevant Pages

  • Re: Storing/Retrieving TYPEs with ALLOCATABLE components (TR) (long)
    ... This is specifically going to disallow putting the array descriptor on ... > the fact that I'm loading an invalid descriptor tBrd%tEn from the file... ... You just can't directly do I/O on objects that have descriptors like that. ... to hide the details of the component I/O. ...
    (comp.lang.fortran)
  • Re: Hard disk drive as big as 1600Gi
    ... things like screen I/O. ... The actual performance will depend on how the array is configured. ... You have the latency times involved in seeking, ... The choice of configuration, will be down to the user. ...
    (alt.comp.periphs.mainboard.asus)
  • Re: disk file reads slow down for file sizes greater than 2 GB
    ... Indeed as you suggest, when the array is allocated and dimensioned to Filesize, ... Specify File Size in Megabytes: ... (and Disk I/O light if one is present). ...
    (comp.lang.fortran)
  • Re: Recursive subroutine for reading null-terminated string
    ... thing as my recursive procedure, but my solution is more elegant/ ... pre-allocated array significantly better than allocating the exact ... and no. Memory allocation can be a significant issue. ... On the other hand, I/O is also a significant speed issue, disk being ...
    (comp.lang.fortran)
  • Re: disk file reads slow down for file sizes greater than 2 GB
    ... > James, John: ... Note that the record length of the I/O transfers is probably irrelevant ... That array ...
    (comp.lang.fortran)