From owner-sc22wg5@open-std.org Wed Jan 21 19:12:47 2009 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 41C3CC178E0; Wed, 21 Jan 2009 19:12:47 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from smtp.llnl.gov (nspiron-3.llnl.gov [128.115.41.83]) by www2.open-std.org (Postfix) with ESMTP id 7A8A0C178D9 for ; Wed, 21 Jan 2009 19:12:45 +0100 (CET) X-Attachments: None Received: from cyrus2.llnl.gov ([128.15.97.105]) by smtp.llnl.gov with ESMTP; 21 Jan 2009 10:12:44 -0800 From: Aleksandar Donev Organization: LLNL To: WG5 , MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] MPI non-blocking transfers Date: Wed, 21 Jan 2009 10:12:43 -0800 User-Agent: KMail/1.9.4 References: <49775A9D.3080102@cray.com> In-Reply-To: <49775A9D.3080102@cray.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200901211012.44002.donev1@llnl.gov> Sender: owner-sc22wg5@open-std.org Precedence: bulk Hi Bill, > Having the buffer automatically acquire this new attribute is > necessary if we want to avoid requiring changes to existing codes. This is raising red flags for me. Existing codes are *buggy*, and trying=20 to somehow make them conforming and well-behaved seems doomed to me.=20 Even for Fortran ASYNCHRONOUS, the user still has to make sure the=20 attribute appears where it needs to. For one thing, the attribute does=20 not "carry over" between scoping units, so if the dummy has the=20 attribute (magically or explicitly), whether the actual needs it or not=20 is a programming question that the compiler cannot answer. Also, I do=20 not now whether in F2003 the interface of a procedure has to specify=20 ASYNCHRONOUS if the dummy gets it implicitly because it is used in=20 async I/O statements inside the routine??? I think we should stay away=20 from magic, it will turn black easily... > > =A0 =A02) 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? > > The question hints at a common confusion.=20 Please answer the actual question. > There are TWO basic problems we are trying to address. Except that the two are tied together, just as WAIT and ASYNCHRONOUS go=20 together (read your answer to question 1). >=A0Various solutions to > this problem have been discussed, most centering on an attribute for > dummy arguments If so, your answer to question 2 is yes? > or coding versions of the MPI routines that accept=20 > pass-by-descriptor rather than > pass-by-address for the buffer argument. Answer to question 2 is no---something new is proposed. Are you=20 proposing something new or do you prefer an ASYNCH_EXTERNAL attribute?=20 Or maybe you prefer not to do anything at all (i.e., ignore the issue). Thanks, Aleks