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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
