On 23/Mar/10 18:37, Sasha Khapyorsky wrote:
On 14:25 Tue 23 Mar , Yevgeny Kliteynik wrote:
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/
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".
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
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
