EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: R3.14.9: Any changes still pending?
From: Andrew Johnson <[email protected]>
To: Ralph Lange <[email protected]>
Cc: EPICS Core Talk <[email protected]>
Date: Thu, 25 Jan 2007 15:03:17 -0600
Ralph Lange wrote:
For the camonitor commandline tool, the output buffer size was set to
a non-zero value in 3.14.7 - for reasons I don't remember.
>
> While I don't see any effects on Linux, a colleague told me that on
> Win32 starting with 3.14.7 he has to ^C the camonitor call the see
> the last lines of output. Which sounds as if the buffer size zero was
> intended to do an implicit flush at each char instead of the end of
> each output line.

This is the current code to do that:

    setvbuf(stdout,NULL,_IOLBF,BUFSIZ);
	   /* Set stdout to line buffering */

Looking at the Linux man page for setvbuf, I don't see anything about what the size parameter is for when passing a NULL to buf.

However, looking at the remarks in Microsoft's online documentation for setvbuf() I find the following:

The array pointed to by buffer is used as the buffer, unless it is
NULL, in which case setvbuf uses an automatically allocated buffer of
length size/2 * 2 bytes.

The mode must be _IOFBF, _IOLBF, or _IONBF. If mode is _IOFBF or
_IOLBF, then size is used as the size of the buffer. If mode is
_IONBF, the stream is unbuffered and size and buffer are ignored.
Values for mode and their meanings are:

_IOFBF

Full buffering; that is, buffer is used as the buffer and size is
used as the size of the buffer. If buffer is NULL, an automatically
allocated buffer size bytes long is used.

_IOLBF

For some systems, this provides line buffering. However, for Win32,
the behavior is the same as _IOFBF - Full Buffering.

I think the latter explains the problem - the MS C runtime doesn't support line buffering. The answer is to explicitly call fflush(stdout) after the print_time_val_sts() call in event_handler - this technique is already used in errlog.c so I know it's portable. All other outputs from the camonitor program are to stderr (which is non-buffered), so that should be sufficient. I'll leave the setvbuf() calls in for now, you can take them out later if you prefer. I'll commit that change.

I don't have a Win system here to test - could someone please check
this and insert a flush call that works on both Win and Linux, so
that every line is appearing at the command line interface when it is
printed?

I've checked that the behaviour is identical on linux and solaris, but I don't have a Windows box myself either; if this hasn't fixed the problem there it may need extra study, in which case I'd want to postpone fixing it until after R3.14.9 anyway.

Thanks,

- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey

References:
R3.14.9: Any changes still pending? Andrew Johnson
Re: R3.14.9: Any changes still pending? Ralph Lange

Navigate by Date:
Prev: FW: R3.14.9: Any changes still pending? Jeff Hill
Next: Re: FW: R3.14.9: Any changes still pending? Ernest L. Williams Jr.
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: R3.14.9: Any changes still pending? Ralph Lange
Next: RE: R3.14.9: Any changes still pending? Jeff Hill
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·