stdio behavior

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by gary.funck on 21 May 2012 at 11:25

[GoogleCodeExporter]

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.

Original comment by phhargr...@lbl.gov on 23 May 2012 at 11:00

[GoogleCodeExporter]

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.

Original comment by phhargr...@lbl.gov on 1 Jun 2012 at 5:11

[GoogleCodeExporter]

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.

Original comment by danbonachea on 15 Jun 2012 at 8:16

[GoogleCodeExporter]

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.

Original comment by gary.funck on 2 Jul 2012 at 4:29

• Added labels: Milestone-Spec-1.4

[GoogleCodeExporter]

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.

Original comment by phhargr...@lbl.gov on 2 Jul 2012 at 5:32