Bug 57140 - fflush can be simplified
fflush can be simplified
Product: eCos
Classification: Retired
Component: C library (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jonathan Larmour
Jonathan Larmour
Depends On:
  Show dependency treegraph
Reported: 2001-12-05 13:21 EST by Jonathan Larmour
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-20 12:07:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan Larmour 2001-12-05 13:21:43 EST
Description of Problem:

From the thread "Fix fflush starvation [#57014]" on ecc-target-changes:

> But I don't see how your change manages this at all.  It seems to me
> that if you enter this [loop] with some other thread holding the lock,
> you'll try once and fail and then immediately just do the
> lock-with-wait.  Or, am I missing something?

The idea was that you may go enter this loop with a stream already locked,
and someone else may do the same, resulting in a potential deadlock.

However, I've just noticed that this is a difference between my[1] code and
the pthread code. In my code Cyg_StdioStream::refill_read_buffer will
already have flushed the stream, whereas in the pthread code, the code in
question deals with all the streams (including the one already locked).

I'll open a bugzilla bug, as I'm not sure exactly what would happen with
!CYGSEM_LIBC_STDIO_WANT_BUFFERED_IO. Right now it would break, but flushing
should be mostly a nop anyway. At the very least, flush_output_unlocked
should call cyg_stdio_flush in that case which it doesn't.
Comment 1 Alex Schuilenburg 2003-06-20 12:07:03 EDT
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=57140

Note You need to log in before you can comment on or make changes to this bug.