This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fflush not always flushing


Humm, i don't think i explained it clearly, or you miss understood
what i've done (or i've misunderstood your reply :-)

Before, it checked to see if the buffer had anything in it. If not, it
simply returned. If it had, it wrote the buffered text and then did a
flush. My problem was that there was nothing in the buffer at this
level, since when flags.buffering is false, write sends it down to the
next layer imeadiately. So, flush turned into NOP. The change i've
made is to take out the initial check to see if there is anything at
this level and NOP if not. If there is, its is written. If there is
not, nothing is written. An unconditional flush is then done, no
matter is there was anything buffered at this level or not.

They key thing here is the unconditional flush. 

     Andrew

On Mon, Sep 30, 2002 at 07:54:40PM +0100, Jonathan Larmour wrote:
> Andrew Lunn wrote:
> >fflush() does not always flush. This little program demonstrates the
> >problem:
> >[snip]
> >fdopen on an interactive device sets up the stream to not do
> >buffering. ie flags.buffering is false. When fprintf does its write to
> >the stream, it passes the output straight down to the next level.
> >When fflush is called, it checks if there is anything in the stream
> >buffer. If there is, it writes it and then call the flush on the level
> >below. Now since the output of fprintf went straight down, the buffer
> >is empty and so the flush is not done and the output can get stuck. 
> >
> >This patch fixes the problem.
> 
> How can it if it also skips the write if len==0? And even if we did the 
> write regardless, if we aren't using the fileio library, we'd still 
> stumble over a check for len==0 in 
> io/common/current/src/iosys.c:cyg_io_write().
> 
> Jifl
> 
> >Index: language/c/libc//stdio/current/src/common/stream.cxx
> >===================================================================
> >RCS file: 
> >/cvs/ecos/ecos/packages/language/c/libc/stdio/current/src/common/stream.cxx,v
> >retrieving revision 1.5
> >diff -u -r1.5 stream.cxx
> >--- language/c/libc//stdio/current/src/common/stream.cxx        23 May 
> >2002 23:07:18 -0000      1.5
> >+++ language/c/libc//stdio/current/src/common/stream.cxx        6 Sep 2002 
> >17:41:20 -0000
> >@@ -543,16 +543,10 @@
> >     if ( !flags.opened_for_write )
> >         return EINVAL;
> > 
> >-    // shortcut if nothing to do
> >-    if (io_buf.get_buffer_space_used() == 0)
> >-        return ENOERR;
> >-        
> >     len = io_buf.get_buffer_addr_to_read( (cyg_uint8 **)&buffer );
> >     
> >-    CYG_ASSERT( len > 0, 
> >-                "There should be data to read but there isn't!");
> >-
> >-    write_err = cyg_stdio_write(my_device, buffer, &len);
> >+    if ( len )
> >+      write_err = cyg_stdio_write(my_device, buffer, &len);
> > 
> >     // since we're doing a concerted flush, we tell the I/O layer to
> >     // flush too, otherwise output may just sit there forever
> >
> 
> 
> -- 
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]