From owner-sc22wg5@open-std.org Wed Jan 21 22:23:52 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 E49EECA3432; Wed, 21 Jan 2009 22:23:52 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by www2.open-std.org (Postfix) with ESMTP id 3542FC178E0 for ; Wed, 21 Jan 2009 22:23:52 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:33226) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:nmm1) id 1LPkYC-0006M0-GF (Exim 4.70) for sc22wg5@open-std.org (return-path ); Wed, 21 Jan 2009 21:23:52 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1LPkYC-0008Rr-0l (Exim 4.67) for sc22wg5@open-std.org (return-path ); Wed, 21 Jan 2009 21:23:52 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 21 Jan 2009 21:23:52 +0000 Date: 21 Jan 2009 21:23:52 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.3866) (j3.2006) MPI non-blocking transfers Message-ID: In-Reply-To: <20090121192815.CB0B0C178D9@www2.open-std.org> References: <20090121110416.958A4C178E0@www2.open-std.org> <20090121192815.CB0B0C178D9@www2.open-std.org> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk >> 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. I am not sure what you mean by this. There is nothing conceptually defective about MPI's non-blocking interfaces, and it has the decency to state most clearly that they require semantics that are outside the standard. The issue is about how to marry them. >> 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. Thanks for the references, and I agree in principle. But we should reserve that discussion for another thread. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679