limit allowed range of values for program exit (via exit or upc_global_exit)

[Former user]

Originally reported on Google Code with ID 90

This issue was split off from Issue 26, which is now restricted to the discussion of
barrier identifiers only.

This issue is related to Issue 45 ("Program exit code: advice to implementers")

GCC/UPC defines a "magic" value to indicate an exit from upc_global_exit(); this value
sets bit 7 (0x80) to indicate that the exit is from upc_global_exit().  Therefore,
the range of values for exit() are constrained to be in the range 0..127.

Would it be possible to define these operations in a way that the runtime can use part
of the value? For example, only positive integers for a barrier value and only values
in the range 0..127 as the return value for upc_global_exit().

Obviously, GCC/UPC can be re−implemented such that these restrictions are removed,
but might it make sense to leave some part of the value range for use by the runtime?

This proposal recommends that ranges of values for both the return code to upc_global_exit()
be restricted in order to allow the underlying UPC runtime and libraries to use values
that are outside the range required by the UPC specification.

Proposed ranges are:

upc_global_exit() and exit() return code argument: 0..127

Impact: there may be some existing applications or test programs that make use of values
outside of the proposed ranges.  These out-of-range values could be detected by the
UPC runtime library so that those use cases can be corrected.

Reported by gary.funck on 2012-09-22 23:20:06

[Former user]

``` In Issue 26, Paul replied:

I don't see the value to the UPC community of reserving any potion of the barrier name space for use by the implementation. Since the UPC spec gives the type of the barrier value as "int", I can expect that UPC codes would want to use the entire range. [...]

I am not touching the exit code question in this comment, because I would want to research what the C and POSIX specs say about exit() first. I don't mean to imply that one MUST follow the spec for exit(), just that I'd like to review it before forming an opinion of UPC's nearest equivalent."

```

Reported by `gary.funck` on 2012-09-22 23:22:27

[Former user]

``` I agree with Paul. It is imprudent to specify anything beyond what C/POSIX say about exit().

What is the benefit of having an exit code bit to distinguish exit() from upc_global_exit() anyways? ```

Reported by `jeff.science` on 2012-09-22 23:57:45

[Former user]

``` In Comment 2: "What is the benefit of having an exit code bit to distinguish exit() from upc_global_exit() anyways?"

For GUPC at least, it simplifies the implementation of upc_global_exit().

Consider a UPC program implemented as a collection of THREADS+1 processes, where P[-1] is a spawning (or monitor) process and p[0] ... P[THREADS-1] map to UPC threads. At present, upc_global_exit(rc) is implemented as exit(0x80 + (rc & 0x7f)). The monitor thread notices that the return code has bit 7 asserted and interprets the UPC thread exit as a global exit; it then kills the remaining threads and ultimately returns the value (0x7f & rc). Without this simple mechanism, some "out of band" method would need to be crafted to communicate that a UPC thread has called upc_global_exit().

Note: at present, the GUPC runtime operates on a single node only, and relies upon SMP-based systems to implement shared memory. Therefore, the GUPC runtime does not use nor depend upon a program launcher such as mpirun or an ssh spawner. I don't know the details of how Berkeley's UPCR, for example deals with ensuring that the return code passed to upc_global_exit() propagates back to the shell command line, and that the remaining UPC threads are terminated. Perhaps active messages are used for this purpose.

In the related issue 45, it might be helpful if the UPC specification did not require that the consensus value of calls to exit is returned from the execution of a program and/or that the value returned is the value passed to upc_global_exit(), because that might leave open other simple strategies for implementing upc_global_exit() without the constraint that the value passed to upc_global_exit() being required to be the value returned from the program. Perhaps in retrospect, aborr() was good enough.

```

Reported by `gary.funck` on 2012-09-23 01:27:01

[Former user]

``` I still think we should not attempt to specify anything about the argument to exit() or upc_global_exit() beyond the C (and perhaps POSIX) spec for exit(). The point of issue #45 is that it is difficult even to be certain what exit code the "spawning command" will observe.

I don't find Gary's implementation-driven argument to be persuasive. In an SMP runtime there are numerous mechanisms available to implement upc_global_exit(). One idea would be for the "-1" thread to spend its life blocked on a read(), or on a select() with a single pipe fd in the read set. A thread requesting a global exit can then write ANY byte to the other end of the pipe just before it exits. When the read() or select() is interrupted by SIGCHLD a read from the pipe will distinguish the global_exit case. If the read() or select() succeeds (a harmless race against the SIGCHLD) then MAYBE one doesn't even need to perform the read to know this is a global exit (need to check if a pipe with no writers is supposed to "wake" a blocked reader, because that condition arises when the last thredd exits "normally"). ```

Reported by `[e-mail]` on 2012-09-27 00:10:40

[Former user]

The issue of exit code behavior (issue 45 & 90) was discussed in the 10/24 telecon.
The consensus was that we don't want to impose any hard requirements at all, and that
we consider it Best Practice for UPC programmers to never rely upon exit code behavior.
We seem to have agreement that the best action is to add a clause to the spec declaring
all exit code behavior as implementation-defined, possibly with stated "preferred behavior".
This will encourage implementers to document their behavior and discourage users from
relying upon non-portable behavior.

Reported by danbonachea on 2012-10-27 03:31:22 - Labels added: Consensus-High - Labels removed: Consensus-Low

[Former user]

At the 11/29 telecon, Gary agreed this issue (limiting the range of exit codes) can
be Rejected.
Issue 45 remains to provide some text as stated in comment 5

Reported by danbonachea on 2012-11-29 20:07:26 - Status changed: Rejected