(j3.2006) Inter-program communication using I/O statements
Fri Jun 6 19:59:15 EDT 2008
On Fri, 2008-06-06 at 15:23 -0500, Bill Long wrote:
> Van Snyder wrote:
> > This brings to mind, however, another possibility:
> > Processors could interpret the FILE= specifier in an OPEN statement and
> > decide to open a connection that would work between programs on a SMP
> > computer (maybe using a FIFO), or node-to-node in a cluster (maybe using
> > MPI), or between workstations in Chile and Antarctica (maybe using
> > SMTP). The processor could use whatever transport method it liked,
> > perhaps choosing a different transport method depending upon the
> > relationship between the guy doing the opening and what is being opened.
> > Some processors might let the user control which transport is selected
> > using an environment variable. Others might encode it in the FILE=
> > string, say "http://192.168.50.250:7237".
> The form of a file name is "processor dependent", and the description of
> an external file is quite abstract. Basically, it's any place outside
> the storage occupied by the program's variables that you can transfer
> values to and/or from. Is there anything in the standard that would
> prevent an implementation from supporting this sort of file name and the
> associated semantics?
I don't think so.
> Processors already use different transport methods depending, for
> example with disk files, whether they are memory resident, on a local
> disk, nfs mounted, part of a lustre file system, ... . I recall that
> with DECnet you could access files on other systems (perhaps in Chile
> or Antarctica) by just tacking node_name:: to the front of the remote
> file's name in the OPEN statement. This is an interesting solution to
> the problem you raised,
Of course, this wouldn't be I/O to a distant file, but I/O to a distant
program. But the "distant file" is really just a distant program (e.g.
NFS) that ends up doing I/O.
> but I don't see its implementation requiring any changes to the
> wording in the standard.
That is my initial reaction, too. The only benefit I can see to adding
a specifier to OPEN, with a scalar-default-char-expr, is to allow
processors not to think about parsing the file name. Support for
inter-program communication via "files" might not be supported in the OS
as conveniently as it was in DECnet. I tried communicating via a fifo
on Linux. It worked fine on one machine with one compiler, but when I
tried it on two machines that shared an NFS-mounted file system (in
which the fifo was located), it didn't work. One compiler thought the
fifo was a terminal and refused to do unformatted I/O. So something
more is needed beyond what Linux provides natively.
Other than that, I don't see any need for changes in the standard.
Van Snyder | What fraction of Americans believe
Van.Snyder at jpl.nasa.gov | Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.
More information about the J3