The current design is a thin layer on top of sockets, just like "info"
is a thin layer on top of string storage. This is helpful to Fortran
users at the cost of some annoyance to C users. It also is more
limiting than sockets. Same old story. MPI's connect/accept, though
theoretically implementable with shmem, in practice they will use
sockets even on shared-memory machines (the accept-side doesn't know
who's going to connect to it and from what host, so as Bill Saphir
pointed out, sockets and select() will be used to bootstrap, and shmem
created afterwards if applicable. IRIX has select()able semaphores, but
my guess is that even there the unneeded complexity will be avoided:
use sockets, call select, read/write a protocol struct to agree on
socket vs. shmem and finish the setup (Eric, correct me if I'm wrong).
Making MPI socket-aware would be good in my opinion. It would make MPI
more useful in general instead of relegating it to a tiny corner of the
computing universe. I wouldn't worry about documentation issues either,
networking/sockets are big business in the documentation world. A big
standard like X Windows has callbacks to attach file descriptors to its
main event loop. Even Microsoft supports sockets! :-) Nothing to
sneeze at. So maybe MPI should go to the mountain instead of wait for
the mountain to come to it.
In any event, I think the main issue at present is whether a referendum
on this would pass by a significant margin to get us to shift gears.
Otherwise we stick to the small niche we carved for connect/accept and
patch the Iaccept() case.
--Raja
-=-
Raja Daoud Hewlett-Packard Co.
raja@rsn.hp.com Convex Division