Here’s another bit of terminology the Fortran spec seemed to feel the need
to invent for itself: talking about “images” to refer to running instances
of a program. I figured this either meant “thread” or “process”, but a
clue appears in the 2018 spec, section 11.4, “STOP and ERROR STOP
statements”:

When an image is terminated by a STOP or ERROR STOP statement, its
stop code, if any, is made available in a processor-dependent
manner. If the stop-code is an integer, it is recommended that the
value be used as the process exit status, if the processor
supports that concept.

So an image “terminates”, and returns a process “exit status”; this must
mean that an “image” is equivalent to a “process”.

On Mon, 26 Feb 2024 00:21:01 +0000, Lawrence D'Oliveiro wrote:

> Here’s another bit of terminology the Fortran spec seemed to feel the
> need to invent for itself: talking about “images” to refer to running
> instances of a program. I figured this either meant “thread” or
> “process”, but a clue appears in the 2018 spec, section 11.4, “STOP and
> ERROR STOP statements”:
>
> When an image is terminated by a STOP or ERROR STOP statement, its
> stop code, if any, is made available in a processor-dependent
> manner. If the stop-code is an integer, it is recommended that the
> value be used as the process exit status, if the processor supports
> that concept.
>
> So an image “terminates”, and returns a process “exit status”; this must
> mean that an “image” is equivalent to a “process”.

Section 3 of the Fortran standard from 2018 defines
the meaning of technical terms. You'll find

3.80
Image
instance of a Fortran program

An 'instance of a Fortran program' could be a grad student
in an office executing her advisor's Fortran program with
pen and paper.

To get a better understand of 'image' see F2018, 5.3.4 Program
execution.

--
steve

On Mon, 26 Feb 2024 01:04:20 -0000 (UTC), Steven G. Kargl wrote:

> 3.80 Image instance of a Fortran program
>
> An 'instance of a Fortran program' could be a grad student in an office
> executing her advisor's Fortran program with pen and paper.

So what is an “Image instance”, how does that relate to an “instance of a
Fortran program”, or to an “image”? And where does a “process” or “process
exit status” come into this?

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
> Here’s another bit of terminology the Fortran spec seemed to feel the need
> to invent for itself: talking about “images” to refer to running instances
> of a program. I figured this either meant “thread” or “process”,

The term is independent of the implementation. Coarrays can be
implemented in a multitude of ways, including threads, processes
or MPI wachamacallits.

And that is the whole point: Implemenations are free to implement
any way they want. Talkling about "threads" on a 1000-node,
24000-core would not make a lot of sense, for example.

>but a
> clue appears in the 2018 spec, section 11.4, “STOP and ERROR STOP
> statements”:
>
> When an image is terminated by a STOP or ERROR STOP statement, its
> stop code, if any, is made available in a processor-dependent
> manner. If the stop-code is an integer, it is recommended that the
> value be used as the process exit status, if the processor
> supports that concept.
>
> So an image “terminates”, and returns a process “exit status”; this must
> mean that an “image” is equivalent to a “process”.

No.

On Mon, 26 Feb 2024 17:50:05 -0000 (UTC), Thomas Koenig wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
>
>> but a clue appears in the 2018 spec, section 11.4, “STOP and ERROR STOP
>> statements”:
>>
>> When an image is terminated by a STOP or ERROR STOP statement, its
>> stop code, if any, is made available in a processor-dependent
>> manner. If the stop-code is an integer, it is recommended that the
>> value be used as the process exit status, if the processor supports
>> that concept.
>>
>> So an image “terminates”, and returns a process “exit status”; this
>> must mean that an “image” is equivalent to a “process”.
>
> No.

But a process can only have one exit status, and an image can only have
one stop code. If there is not a 1:1 correspondence between them, then
what?

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
> On Mon, 26 Feb 2024 17:50:05 -0000 (UTC), Thomas Koenig wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
>>
>>> but a clue appears in the 2018 spec, section 11.4, “STOP and ERROR STOP
>>> statements”:
>>>
>>> When an image is terminated by a STOP or ERROR STOP statement, its
>>> stop code, if any, is made available in a processor-dependent
>>> manner. If the stop-code is an integer, it is recommended that the
>>> value be used as the process exit status, if the processor supports
>>> that concept.
>>>
>>> So an image “terminates”, and returns a process “exit status”; this
>>> must mean that an “image” is equivalent to a “process”.
>>
>> No.
>
> But a process can only have one exit status, and an image can only have
> one stop code. If there is not a 1:1 correspondence between them, then
> what?

The answer is in the standard: "processor-dependent", so an
implementation is free to do whatever its writers feel like doing.
It could write to standard error, it could return an exit code,
or it could send a carrier pigeon (which would require the right
operational hardware) or an e-mail.

You're making the mistake of trying to fit a single concept to
something that is deliberately left as processor-dependent in the
standard. It doesn't fit (as I explained in the part you snipped).