public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
* opensm/main.c: foce stdout to be line-buffered
@ 2010-03-03  8:26 Yevgeny Kliteynik
       [not found] ` <4B8E1D46.4090106-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
  0 siblings, 1 reply; 6+ messages in thread
From: Yevgeny Kliteynik @ 2010-03-03  8:26 UTC (permalink / raw)
  To: Sasha Khapyorsky; +Cc: Linux RDMA

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 <kliteyn-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
---
 opensm/opensm/main.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

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

+	/* force stdout to be line-buffered */
+	setlinebuf(stdout);
+
 	/* 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: opensm/main.c: foce stdout to be line-buffered
       [not found] ` <4B8E1D46.4090106-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2010-03-23 10:37   ` Sasha Khapyorsky
  2010-03-23 12:25     ` Yevgeny Kliteynik
  0 siblings, 1 reply; 6+ messages in thread
From: Sasha Khapyorsky @ 2010-03-23 10:37 UTC (permalink / raw)
  To: Yevgeny Kliteynik; +Cc: Linux RDMA

Hi Yevgeny,

On 10:26 Wed 03 Mar     , Yevgeny Kliteynik wrote:
> 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?

> 
> Forcing stdout to always be line-buffered.
> 
> Signed-off-by: Yevgeny Kliteynik <kliteyn-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
> ---
>  opensm/opensm/main.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/opensm/opensm/main.c b/opensm/opensm/main.c
> index f9a33af..5ea65dd 100644
> --- a/opensm/opensm/main.c
> +++ b/opensm/opensm/main.c
> @@ -613,6 +613,9 @@ int main(int argc, char *argv[])
>  		{NULL, 0, NULL, 0}	/* Required at the end of the array */
>  	};
> 
> +	/* force stdout to be line-buffered */
> +	setlinebuf(stdout);

What about stderr? IOW describe your problem in more details (see above).

Sasha

> +
>  	/* 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: opensm/main.c: foce stdout to be line-buffered
  2010-03-23 10:37   ` Sasha Khapyorsky
@ 2010-03-23 12:25     ` Yevgeny Kliteynik
       [not found]       ` <4BA8B33E.8000003-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
  0 siblings, 1 reply; 6+ messages in thread
From: Yevgeny Kliteynik @ 2010-03-23 12:25 UTC (permalink / raw)
  To: Sasha Khapyorsky; +Cc: Linux RDMA

Hi Sasha,

On 23/Mar/10 12:37, Sasha Khapyorsky wrote:
> Hi Yevgeny,
>
> On 10:26 Wed 03 Mar     , Yevgeny Kliteynik wrote:
>> 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?

The problematic case is 'opensm > somefile'.
  
> Would '-d2' option be related to the issue?

'-d2' refers to the log file, I'm talking about
printf to stdout.

>>
>> Forcing stdout to always be line-buffered.
>>
>> Signed-off-by: Yevgeny Kliteynik<kliteyn-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
>> ---
>>   opensm/opensm/main.c |    3 +++
>>   1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/opensm/opensm/main.c b/opensm/opensm/main.c
>> index f9a33af..5ea65dd 100644
>> --- a/opensm/opensm/main.c
>> +++ b/opensm/opensm/main.c
>> @@ -613,6 +613,9 @@ int main(int argc, char *argv[])
>>   		{NULL, 0, NULL, 0}	/* Required at the end of the array */
>>   	};
>>
>> +	/* force stdout to be line-buffered */
>> +	setlinebuf(stdout);
>
> What about stderr?

stderr is always unbuffered, no matter where
is stderr actually assigned to.

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

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/

-- Yevgeny

> Sasha
>
>> +
>>   	/* 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: opensm/main.c: foce stdout to be line-buffered
       [not found]       ` <4BA8B33E.8000003-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2010-03-23 16:37         ` Sasha Khapyorsky
  2010-03-23 21:36           ` Yevgeny Kliteynik
  0 siblings, 1 reply; 6+ messages in thread
From: Sasha Khapyorsky @ 2010-03-23 16:37 UTC (permalink / raw)
  To: Yevgeny Kliteynik; +Cc: Linux RDMA

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

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

Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: opensm/main.c: foce stdout to be line-buffered
  2010-03-23 16:37         ` Sasha Khapyorsky
@ 2010-03-23 21:36           ` Yevgeny Kliteynik
       [not found]             ` <4BA9344A.6010007-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
  0 siblings, 1 reply; 6+ messages in thread
From: Yevgeny Kliteynik @ 2010-03-23 21:36 UTC (permalink / raw)
  To: Sasha Khapyorsky; +Cc: Linux RDMA

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: opensm/main.c: foce stdout to be line-buffered
       [not found]             ` <4BA9344A.6010007-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2010-03-24  7:09               ` Yevgeny Kliteynik
  0 siblings, 0 replies; 6+ messages in thread
From: Yevgeny Kliteynik @ 2010-03-24  7:09 UTC (permalink / raw)
  To: Sasha Khapyorsky; +Cc: Linux RDMA

On 23/Mar/10 23:36, Yevgeny Kliteynik wrote:
> 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".

Correction: the coreutils package is common, stdbuf isn't -
it was added in coreutils 7.5.
For instance, RH 5.3 has version 5.97, SLES 11 has version
6.12

-- Yevgeny

>> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-03-24  7:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-03  8:26 opensm/main.c: foce stdout to be line-buffered Yevgeny Kliteynik
     [not found] ` <4B8E1D46.4090106-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2010-03-23 10:37   ` Sasha Khapyorsky
2010-03-23 12:25     ` Yevgeny Kliteynik
     [not found]       ` <4BA8B33E.8000003-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2010-03-23 16:37         ` Sasha Khapyorsky
2010-03-23 21:36           ` Yevgeny Kliteynik
     [not found]             ` <4BA9344A.6010007-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2010-03-24  7:09               ` Yevgeny Kliteynik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox