From owner-sc22wg5@open-std.org  Wed Jan 21 20:28:15 2009
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id A58BAC178E0; Wed, 21 Jan 2009 20:28:15 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105])
	by www2.open-std.org (Postfix) with ESMTP id B3716C178D9
	for <sc22wg5@open-std.org>; Wed, 21 Jan 2009 20:28:13 +0100 (CET)
Received: from mprox3.jpl.nasa.gov (mprox3.jpl.nasa.gov [137.78.160.171])
	by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0LJS9aL028330
	for <sc22wg5@open-std.org>; Wed, 21 Jan 2009 19:28:09 GMT
Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57])
	(authenticated bits=0)
	by mprox3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0LJS8rr021710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <sc22wg5@open-std.org>; Wed, 21 Jan 2009 11:28:08 -0800
Subject: Re: (j3.2006) (SC22WG5.3861) MPI non-blocking transfers
From: Van Snyder <Van.Snyder@jpl.nasa.gov>
Reply-To: Van.Snyder@jpl.nasa.gov
Cc: WG5 <sc22wg5@open-std.org>
In-Reply-To: <20090121110416.958A4C178E0@www2.open-std.org>
References: <20090121110416.958A4C178E0@www2.open-std.org>
Content-Type: text/plain
Organization: Yes
Date: Wed, 21 Jan 2009 11:28:07 -0800
Message-Id: <1232566088.15119.656.camel@math.jpl.nasa.gov>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.3) 
Content-Transfer-Encoding: 7bit
X-Source-IP: math.jpl.nasa.gov [137.79.7.57]
X-Source-Sender: Van.Snyder@jpl.nasa.gov
X-AUTH: Authorized
Sender: owner-sc22wg5@open-std.org
Precedence: bulk


>     1) Most people seem to agree that the semantics of the buffers used
> for MPI non-blocking transfers and pending input/output storage
> affectors are essentially identical, with READ, WRITE and WAIT
> corresponding to MPI_Isend, MPI_IRecv and MPI_Wait (and variations).
> 
> Do you agree with this and, if not, why not?

Yes, but we already have READ, WRITE and WAIT

> 
>     2) Most people seem to agree that a data attribute is essential, and
> a purely procedure-based solution will not work.
> 
> Do you agree with this and, if not, why not?

We needed one for I/O, but we ought not to need one for interaction with
procedures having defective interfaces.

>     3) It would be very easy to extend the wording of the ASYNCHRONOUS
> attribute etc. to allow for asynchronous I/O started and completed by a
> companion processor (including MPI, here).  It would also be very easy
> to add a new one (say, ASYNCH_EXTERNAL), with the same properties, but
> applying only to companion processor I/O.
> 
> Do you think that adding a new attribute is desirable and, if so, why?

No, because we already have one with the desired functionality

>     4) For Fortran asynchronous I/O, the processor obviously knows when
> an input/output storage affector becomes and ceases to be pending.  From
> the point of view of program correctness, this information is not
> needed, but it might be useful for implementors.  I proposed such a
> mechanism, but it seemed to confuse some people.
> 
> Do you believe that there needs to be a standardised mechanism for the
> companion processor to inform the Fortran processor of such state
> changes and, in either case, why or why not?

No.  I/O should be done with I/O statements.  Truckling to a defective
interface is silly.  I've already proposed two mechanisms to do
inter-program transport using I/O statements, one of which can be
connected to MPI or PVM or whatever your favorite transport protocol is.
See 08-204 and 08-205.