You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2003/06/04 17:01:05 UTC

DO NOT REPLY [Bug 20295] - apr_file_write_full() to pipe with timeout can return EAGAIN

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20295>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20295

apr_file_write_full() to pipe with timeout can return EAGAIN

trawick@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|mod_cgi                     |APR
            Product|Apache httpd-2.0            |APR
            Summary|Uploading large             |apr_file_write_full() to
                   |multipart/form-data         |pipe with timeout can return
                   |sometimes fails             |EAGAIN
            Version|2.0.45                      |HEAD



------- Additional Comments From trawick@apache.org  2003-06-04 15:01 -------
great work!

I've updated http://www.apache.org/~trawick/PR20295/writefull.c to take two
optional arguments: iterations and bytes-per-iteration, and I can see the
failure (getting EAGAIN unexpectedly) on both HP-UX 11.00 and 11i.

With 8000 bytes per iteration I have to run it more than 10 times to see the
failure.  There is something about the timing.  If I just do

./a.out 20 8000

I'll rarely see 11, but if I do 

./a.out 20 8000 | grep 11

I hit it constantly.

I'd think that requiring the test program to report results to a pipe for every
call would give swallow.pl a chance to empty the pipe more often and result in
the test program getting EAGAIN less frequently.  Instead, the opposite is true
:)  (I guess swallow.pl is being deprived of cycles required to empty its side
of the pipe because of the extra grep).

For the moment I've changed the product to APR since that is where the problem
lies.  apr_file_write_full() shouldn't be returning EAGAIN on a pipe that has an
APR timeout set. It will be APR's job to remedy the situation.

I've played with writefull.c on Linux so far with no bogosities; I want to try
it on some other systems with various parameters to get more confidence in the
theory that this is HP-UX-specific behavior that needs to be fixed/worked-around
and not a general problem in APR that happens to show up more readily on HP-UX
because of different kernel pipe buffer sizes or different scheduling behavior
or whatever.

Thanks for the report and for your work in uncovering the root cause!  With any
luck a straightforward solution with no extra scheduling will be possible.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org