stdio behavior

[Former user]

Originally reported on Google Code with ID 28 ``` This proposal is responsive to issue 25.

25. How is the behavior of stdio defined in UPC? Can ideas from MPI definition be borrowed here?

At present there are no specific recommendations for additions/clarifications to be added to the UPC language specification that might serve to desribe the required I/O behavior of a UPC program.

Attach specific proposals to this issue.

```

Reported by `gary.funck` on 2012-05-21 23:25:51

[Former user]

``` Presently it seems that users of UPC expect, at a minimum, that stdout and stderr make it to the "right place", which may be the stdout/stderr of the "launching" process, or in some cases files specified to that launching process or its environment.

What seems to "frustrate" certain benchmarks we've seen is the implicit assumption some are making that concurrent output from multiple threads is a safe practice. In general, the Berkeley implementation makes no effort to, for instance, line-buffer the stdout and stderr in such a way as to prevent "poorly interleaved" output from multiple threads. Example, given 2 threads and the following code: printf(" Thread %i done.\n", MYTHREAD); The programmer expects Thread 0 done. Thread 1 done. or Thread 1 done. Thread 0 done. but is NOT expecting Threa Thread 0 done. d 1 done.

Since I hope nobody expects stdout/stderr to be high-bandwidth output channels, I would not object too strongly if there were a consensus that an implementation must guarantee concurrent output from multiple threads is interleaved at LINE granularity (with some bounded length to avoid unbounded buffering) rather than arbitrarily. However, my preference would be simply to document for the UPC user that the spec does NOT ensure any such thing and that one must therefore take appropriate care when multiple threads may generate stdout/stderr concurrently.

I am not aware of any expectations users have with regards to stdin. I would loath ensuring any specific behaviors with respect to stdin, and would not object at all if the spec were to say that stdin is closed prior to main().

NOTE: while I mention specific ideas (line-buffered stdout/etderr and closed stdin), I am *not* putting anything forward as proposals. Those are ideas to start the discussion and I don't claim they are the *best* ideas available. ```

Reported by `[e-mail]` on 2012-05-23 23:00:36

[Former user]

``` For better or worse, the current spec includes the following footnote in 5.1.2.1:

[4] e.g., in the program main(){ printf("hello"); } , each thread prints hello.

So, we seem to have promised that stdout operates in all threads.

```

Reported by `[e-mail]` on 2012-06-01 05:11:07

[Former user]

``` As an implementer I do not like the idea of requiring UPC implementations to line-buffer stdout/stderr. This may be tractable in monolithic implementations, but can become very nasty for portable implementations that use the system libstdio and support a wide variety of distributed job managers. For the same reason I'd also agree with Paul in favor of stating that stdin is closed before main (which incidentally also resolves many semantic questions about the multiplexing of stdin). I don't know what the user reaction to this might be.

As background here are the relevant sections in C99: 7.9.13 At program startup, three text streams are predefined and need not be opened explicitly — standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output). As initially opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device. ... When a stream is unbuffered, characters are intended to appear from the source or at the destination as soon as possible. Otherwise characters may be accumulated and transmitted to or from the host environment as a block. When a stream is fully buffered, characters are intended to be transmitted to or from the host environment as a block when a buffer is filled. When a stream is line buffered, characters are intended to be transmitted to or from the host environment as a block when a new-line character is encountered. Furthermore, characters are intended to be transmitted as a block to the host environment when a buffer is filled, when input is requested on an unbuffered stream, or when input is requested on a line buffered stream that requires the transmission of characters from the host environment. Support for these characteristics is implementation-defined, and may be affected via the setbuf and setvbuf functions.

```

Reported by `danbonachea` on 2012-06-15 08:16:38

[Former user]

``` Reading the discussion, it seems there are various non-obvious implementation and user-level issues that need to be considered for this issue to move forward to resolution. Tagged for specification 1.4.

If any reviewers would prefer that this issue be re-prioritized and considered for 1.3, please update the status accordingly.

```

Reported by `gary.funck` on 2012-07-02 16:29:29 - Labels added: Milestone-Spec-1.4

[Former user]

``` I have no objection to the move to 1.4 for this issue, and even think that reaching actual agreement on stdio behavior before 2.0 may be too optimistic. ```

Reported by `[e-mail]` on 2012-07-02 17:32:09