(j3.2006) Inter-program communication using I/O statements

[Van Snyder]

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.