From rz48@rz.uni-karlsruhe.de  Thu Feb  6 13:29:35 1997
Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id NAA27136 for <sc22wg5@dkuug.dk>; Thu, 6 Feb 1997 13:26:08 +0100
Message-Id: <199702061226.NAA27136@dkuug.dk>
Received: from ry73.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Thu, 6 Feb 1997 13:25:08 +0100
Received: by ry73.rz.uni-karlsruhe.de
	(1.38.193.4/16.2) id AA04365; Thu, 6 Feb 1997 13:24:40 +0100
Subject: Comment on 97-102 (ASYNC I/O)
To: bleikamp@rsn.hp.com
Date: Thu, 6 Feb 1997 13:24:40 +0100 (CET)
Cc: sc22wg5@dkuug.dk
From: hennecke@rz.uni-karlsruhe.de (Michael Hennecke)
Reply-To: hennecke@rz.uni-karlsruhe.de (Michael Hennecke)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Length: 2560      

Dear Rich,
    
>                                                         WG5/N1245
>                                                       X3J3/97-102
>                                                      page 9 of 16
>
>   |    When a READ statement with the ASYNCHRONOUS
>   |    specifier is executed, the program shall not execute
>   |    any procedure call where any variable :
>   |      1) in the input / output list or namelist,
[snip]
>   |    or subobject or parent object thereof, is passed as an
>   |    actual argument, until the corresponding wait operation
>   |    is executed, unless :
[snip]
>   |      2) the corresponding dummy argument is an assumed
>   |         shape array
>   |
>   |     Note: This restriction prevents interactions between
>   |           actual arguments passed with so-called
>   |           copyin/copyout semantics and asynchronous I/O.
>
>       Question:  Should we allow scalars?  Can they be passed
>       by copyin/out?  Any other ways to force pass by address
>       or descriptor?

to my understanding, it is not sufficient for the dummy argument to
be an assumed shape array. At a CALL PROC(A(::2)) a dumb implementation
might still copy A(::2) to TMP(1:SIZE(A)/2), and put the address of
that TMP and TMP's length into an (ALLOCATABLE-like) descriptor, rather
than putting the address of A plus length and stride information into a
(POINTER-like) descriptor. Am I right?

I also think that the standard does not enforce pass by address for scalars,
so allowing them might lead (processor-depending) to strange effects.

How about allowing all this, and putting some requirement on the processor
to reject such code if it has a dumb implementation of assumed shape,
passes scalars by value, or does other COPYIN/COPYOUT where the async
stuff cannot allow that? The program would then rely on a processor-dependent
feature, and the processor would be responsible to tell if it cannot
handle it as expected.

Thanks,
Michael

 ======================================================================
  Michael Hennecke      http://www.uni-karlsruhe.de/~Michael.Hennecke/ 
 ----------------------------------------------------------------------
  University of Karlsruhe         RFC822: hennecke@rz.uni-karlsruhe.de 
  Computing Center (G20.21 R210)               No longer on BITNET :-(
  Zirkel 2  *  P.O. Box 69 80                 Phone: +49 721  608-4862 
  D-76128  Karlsruhe                               Fax: +49 721  32550 
 ======================================================================