opensm/main.c: foce stdout to be line-buffered

When stdout is assigned to a terminal, it is line-buffered. But when opensm's stdout is redirected to a file, stdout becomes block-buffered, which means that '\n' won't cause the buffer to be flushed.

Forcing stdout to always be line-buffered.

Signed-off-by Yevgeny Kliteynik <[email protected]>

---
 opensm/opensm/main.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

opensm/opensm/main.c +0 -0

index f9a33af..5ea65dd 100644

opensm/opensm/main.c +1 -0

+
 	/* Make sure that the opensm and complib were compiled using
 	   same modes (debug/free) */
 	if (osm_is_debug() != cl_is_debug()) {

Signature · 6 lines

1.5.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Yevgeny,

Quoted 4 lines · Yevgeny Kliteynik

When stdout is assigned to a terminal, it is line-buffered. But when opensm's stdout is redirected to a file, stdout becomes block-buffered, which means that '\n' won't cause the buffer to be flushed.

Such redirection happens in daemon mode. Another case would be 'opensm> somefile '. Where do you see the problem?

Would '-d2' option be related to the issue?

Quoted 16 lines

Forcing stdout to always be line-buffered.

Signed-off-by Yevgeny Kliteynik<[email protected]>

---
  opensm/opensm/main.c |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

opensm/opensm/main.c +0 -0

index f9a33af..5ea65dd 100644
@@ -613,6 +613,9 @@ int main(int argc, char *argv[])
  		{NULL, 0, NULL, 0}	/* Required at the end of the array */
  	};
 

opensm/opensm/main.c int main(int argc, char *argv[]) · line 617

Quoted 2 lines

opensm/opensm/main.c +2 -0

+	/* force stdout to be line-buffered */
+	setlinebuf(stdout);

What about stderr?

IOW describe your problem in more details (see above).

Sasha

Quoted 12 lines

opensm/opensm/main.c +1 -1

+
  	/* Make sure that the opensm and complib were compiled using
  	   same modes (debug/free) */
  	if (osm_is_debug() != cl_is_debug()) {
--

1.5.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

I'm running "opensm > somefile", and I don't see SM's stdout (such as "SUBNET UP" message, or new cached options after SIGHUP), because when stdout is assigned to file and not terminal, it is handled differently. Instead of flushing on printing '\n', it becomes buffered, which means that you don't control when is this buffer flushed.
My fix forces stdout to always flush stdout when printing '\n'. It has no effect when stdout is assigned to terminal, and it changes buffering when SM's stdout is redirected.

More details about stdout/stderr buffering:

http://www.pixelbeat.org/programming/stdio_buffering/

Quoted 11 lines · Yevgeny Kliteynik

I'm running "opensm> somefile", and I don't see SM's stdout (such as "SUBNET UP" message, or new cached options after SIGHUP), because when stdout is assigned to file and not terminal, it is handled differently. Instead of flushing on printing '\n', it becomes buffered, which means that you don't control when is this buffer flushed.
My fix forces stdout to always flush stdout when printing '\n'. It has no effect when stdout is assigned to terminal, and it changes buffering when SM's stdout is redirected.

Quoted 3 lines

More details about stdout/stderr buffering:

http://www.pixelbeat.org/programming/stdio_buffering/

There you can find couple of ways to workaround this issue, for example:

stdbuf -o L opensm> somefile

I would prefer to not change an external settings so the program would work as expected.

Sasha

Quoted 16 lines · Sasha Khapyorsky

Quoted 14 lines · Yevgeny Kliteynik

I'm running "opensm> somefile", and I don't see SM's stdout (such as "SUBNET UP" message, or new cached options after SIGHUP), because when stdout is assigned to file and not terminal, it is handled differently. Instead of flushing on printing '\n', it becomes buffered, which means that you don't control when is this buffer flushed.
My fix forces stdout to always flush stdout when printing '\n'. It has no effect when stdout is assigned to terminal, and it changes buffering when SM's stdout is redirected.

More details about stdout/stderr buffering:

http://www.pixelbeat.org/programming/stdio_buffering/

Quoted 3 lines

There you can find couple of ways to workaround this issue, for example:

stdbuf -o L opensm> somefile

This is not a usual shell command, nor some common tool that is used in Linux distros. It's just a tool that is provided in some package called "coreutils 7.5".

Quoted 2 lines

I would prefer to not change an external settings so the program would work as expected.

IMHO, on the contrary - the expected behavior
would be achieved with the patch.

But in any case, what exactly seems problematic here?

I can't see any impact on any aspect whatsoever. It is somehow related to performance (more flushes when the stream is line-buffered instead of just buffered), but we're talking about stdout here, not the log file, so the performance is not affected too.

-- Yevgeny

Quoted 2 lines

Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html