(j3.2006) (SC22WG5.3624) [ukfortran] A comment on John Wallin's comments on Nick MacLaren's comments

[Van Snyder]

On Wed, 2008-11-05 at 14:56 -0800, N.M. Maclaren wrote:
> On Nov 5 2008, Van Snyder wrote:
> >
> >I remarked on this problem before m185, and proposed a trivial addition
> >to the OPEN statement to allow message passing using I/O statements,
> >which already know how to do DTIO and asynchronous, in 08-204.  Subgroup
> >didn't even consider it.
> >
> >If coarrays are kicked off the train in Tokyo, we really should go back
> >and look at the directions proposed in 08-204 and 08-205.  Fortran I/O
> >applied to message passing should provide all the basic functionality of
> >MPI, and would be far clearer.
> 
> Er, no.  They would provide the point-to-point functionality, but that is
> not quite the same.  In my MPI course, I teach collectives as the basic
> functionality, and point-to-point as the specialist feature!

I guess it depends upon your view of "basic."

> However, I am not saying that internal FIFOs aren't a good communication
> mechanism - far from it - merely that MPI is more than that.

It must be far more, since it takes 406 pages to describe it, while all
of Fortran I/O takes "only" 74 pages (in 08-007r1).  Putting loops
around point-to-point using Fortran I/O still seems simpler than 406
pages of MPI.  Sure, you might get a performance benefit by broadcasting
the buffer once the I/O list is processed into it, but it wouldn't be
difficult to allow the unit in a WRITE statement to be an array (and
this might be useful independently of inter-program communication).

> >Within a single SMP, say a dual quad-core PC, one can already accomplish
> >what's proposed in 08-204 with a pipe, but I haven't met a system yet
> >where pipes work across NFS.  08-204 provides syntax for users to hook
> >to stuff that vendors provide that go beyond NFS.  08-205 provides a way
> >for users to roll their own, perhaps atop MPI, while hiding the ugly
> >details behind I/O statements.
> 
> I am not quite sure what you mean. The basic FIFO aspect of pipes is
> preserved across NFS - if you are referring to multiple sources or multiple
> sinks, that is going a bit beyond pipes. And, of course, there is nothing
> stated about when data is transferred - but that is true even of local
> pipes.

Maybe I just haven't been holding my mouth right, or maybe I didn't
explain the correct problem.  My home directory is on a file server that
is NFS mounted onto my computer.  When I do this on my computer:

# mkfifo foo
# echo something > foo

and then open another xterm on the same computer and do

# cat foo

it prints "something". So my computer has no problem reading the
directory information using NFS and discovering that "foo" is a fifo.

If I log one of the xterms into another computer that has access to the
same file system, it doesn't work.  Both of them just sit there.
Indeed, the xterm with the "echo" needs to be killed -- I can't kill the
"echo".

I also wrote two little Fortran programs that opened a formatted file.
One read from stdin and wrote to the file, the other read from the file
and wrote to stdout.  If the file is a fifo and both programs run on the
same computer, the read->stdout program prints what I input to the
stdin->write program.  But if I run them on different computers that
have access to the same file system, they both hang.

All of this on CentOS 5, but I got the same results on RedHat Fedora 9.
We don't have any Suns or HPs any more.  Does Windoze even have fifos?
I haven't tried it on Mac OS X.

I also tried this on two nodes of one of our Linux-based clusters,
hoping there was something extra in the OS to make it work, but it
didn't.

Is there a system where this works?  Does it work on Linux if I do it
"right?"

Is there a different way to do it?

> What definitely is the case is that the metadata and contents can get out of
> of sync in NFS version 3, even in the simplest configurations.  But a pure
> pipe doesn't rely on stat().
> 
> Regards,
> Nick Maclaren,
> University of Cambridge Computing Service,
> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
> Email:  nmm1 at cam.ac.uk
> Tel.:  +44 1223 334761    Fax:  +44 1223 334679
> 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3