(j3.2006) (SC22WG5.5421) Preliminary result of the WG5 straw ballot on N2040

[Robert Corbett]

On 1/17/2015 3:08 AM, John Reid wrote:
> WG5,
>
> Here is the preliminary result of the WG5 straw ballot on N2040. 
> Several people that usually voted have not done so this time. If any 
> of you do so very soon, I will include your vote.

I sent the following ballot yesterday.  I used my personal e-mail 
account instead of my Oracle account, because Oracle's mail server was 
not respoding at the time.

Robert Corbett

"Is N2040 ready for forwarding to SC22 as the DTS?"

My vote is 3) No, for the following reasons.

Robert Corbett

------------------------------

I am still concerned about the features described in Clause 5.9
I understand that allowing stalled images to resume execution
is a desired feature.  I am not convinced that the feature as
described in the DTS can be implemented without imposing a
severe performance penalty.  I understand that the ability to
resume stalled images is an optional feature.  I think that
even an optional feature should be required to be implementable.

I would change my vote if a description of how the feature could
be implemented is provided, assuming that the proposed
implementation is reasonable.  (Implementation via an interpreter,
for example, would not satisfy me.)  I would like the proposed
implementation to be based on hardware and systems software that
is commonly available.  A proposal for an implementation for
x86/x64 Linux would be fine.  The description of TS.  A separate
paper, not subject to approval would suffice.

One implementation proposal I shall not accept is that the
implementation should be the same as whatever the GCC
implementation of C++ does for exception handling.  I spoke
with a member of Oracle's C++ team, and he said that Oracle's
implementation of C++ exception handling could not do
everything I told him the DTS requires.

The DTS imposes some implicit requirements on processors.  For
example, some Fortran features require an implementation to
perform synchronization.  An implementation of a CRITICAL
construct, a SYNC ALL statement, a parallel reduction, or
input/output is likely to involve synchronization.  If an
image stalls on a data reference during the execution of a
CRITICAL construct within the scope of execution of a CHANGE
TEAM construct, I assume that the DTS assumes that a lock
held by the image as part of the synchronization done for
the CRITICAL construct must be released before execution of
of the stalled image resumes.

The DTS does not appear to impose a requirement that storage
allocated during execution of a stalled image be released before
execution of the stalled image resumes.  Is the possible memory
leak permitted?

Fortran processors often acquire system resources during execution.
For example, some operating systems allow a process to use at most
a fixed number of locks and events.  To avoid running out of the
system resources, the process must release resources it acquired
when it no longer needs them.  Is it intended that the DTS require
that a process release such resources as are no longer needed when
an associated stalled image resumes execution, or is it a quality
of implementation issue?