[ECOS] Starvation in cyg_libc_stdio_flush_all_but()?
David Airlie
David.Airlie@parthus.com
Mon Dec 3 07:31:00 GMT 2001
I think I had something like this fixed by
diff -u -r1.1 -r1.2
--- ecos/packages/language/c/libc/stdio/current/src/common/fflush.cxx 2001/04/19 16:06:09 1.1
+++ ecos/packages/language/c/libc/stdio/current/src/common/fflush.cxx 2001/12/03 15:27:25 1.2
@@ -86,7 +86,10 @@
} // if
else {
// valid stream
-
+#ifdef CYGSEM_LIBC_STDIO_WANT_BUFFERED_IO
+ if(!stream->flags.last_buffer_op_was_read)
+#endif
+ {
if ( stream->trylock_me() ) {
err = stream->flush_output_unlocked();
stream->unlock_me();
@@ -94,6 +97,7 @@
} // if
else
loop_again = true;
+ }
} // else
} // if
} // for
this is in CVS at the time I found it in my tree.. so I just stole the fix
from CVS..
let me know if it works..
Dave.
On 3 Dec 2001, Robin Farine wrote:
> Hi,
>
> Under some circumstances, my application's UI freezes but background threads
> still run. The following scenario causes it to happen:
>
> 1. Two threads; one, called CLI, handles the command line interface. The
> second, say WRK, does some work and prints messages to the console.
>
> 2. priority(CLI) > priority(WRK) (higher priority, not higher value)
>
> 3. While WRK is printing a message to stdout, the user hits RETURN which
> causes the CLI thread to wake up and display a prompt to stderr. This ends
> in cyg_libc_stdio_flush_all_but() with the CLI thread looping endlessly
> trying to flush stdout since WRK owns stdout stream's lock and cannot
> release it because of its lower priority.
>
> Did anyone already have this problem? Do the current CVS sources fix it?
>
>
> Thanks,
>
> Robin
>
--
David Airlie, Software Engineer, Parthus Technologies plc.,
Mary Rosse Centre, National Tech Park, Limerick, Ireland.
t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com
More information about the Ecos-discuss
mailing list