This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 60028 - write() on a full pipe blocks after select() claims the file descriptor is writable.
write() on a full pipe blocks after select() claims the file descriptor is wr...
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-19 01:20 EST by Sam Varshavchik
Modified: 2007-04-18 12:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-19 03:54:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program to reproduce this behavior. (615 bytes, text/plain)
2002-02-19 01:21 EST, Sam Varshavchik
no flags Details

  None (edit)
Description Sam Varshavchik 2002-02-19 01:20:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205

Description of problem:

When I have a full pipe, select() claims that the pipe's file descriptor is
writable, but a write() on the pipe blocks immediately.  I'm pretty sure this
breaks POSIX compliance.

Version-Release number of selected component (if applicable):

kernel 2.4.9-21 errata for Red Hat Linux 7.2 (not verified with prior kernel revs).

How reproducible:
Always

Steps to Reproduce:
1. Install kernel 2.4.9-21 errata for Red Hat Linux 7.2
2. Compile the attached test program.
3. Run the test program under strace:

# strace testprogram

	

Actual Results:  Output from strace:

...

dup2(4, 1)                              = 1
select(2, NULL, [1], NULL, NULL)        = 1 (out [1])
write(1, "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"..., 8192

The process now remains blocked in the write syscall at this point, until the
process is killed.


Expected Results:  I expect one of two POSIX compliant behaviors:

1) select() blocks until the pipe is not blocked, or:

2) select() indicates that the pipe is available for writing, but the subsequent
write() is only partially completed.
Comment 1 Sam Varshavchik 2002-02-19 01:21:19 EST
Created attachment 45940 [details]
Test program to reproduce this behavior.
Comment 2 Alan Cox 2002-02-19 04:30:28 EST
I don't think it breaks SUSv3/POSIX compliance. From the standards document
"* If the O_NONBLOCK flag is clear, a write request may cause the thread to
block, but on normal completion it shall return nbytes"

On select it says:
"A descriptor shall be considered ready for writing when a call to an output
function with O_NONBLOCK clear would not block, whether or not the function
would transfer data successfully"

So once the pipe has at least one byte of room the select should say ready, and
a blocking 8K write should block.



.

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