I'll probably have time to work on the changes to ap_core_input_filter
and/or
the async read code this weekend (starting on the async-read-dev branch).
If anyone has a strong argument for or against putting the buffering of
partial lines inside the ap_core_input_filter context, please speak up.
On Jan 3, 2006, at 8:07 AM, Justin Erenkrantz wrote:
AFAICT, ap_read_async_request() on the branch can't handle a partial
line correctly.
Noting of course that ap_core_input_filter is 'cute' and masks EAGAIN.
So, you'll never see EAGAIN from this code path! As I said earlier,
the EAGAIN
Roy T. Fielding wrote:
On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote:
Now, if you want to tell me that those changes produced a net
performance benefit on prefork (and thus are applicable to other MPMs),
then I am all ears. I am easily convinced by comparative performance
figures when
On Jan 2, 2006, at 3:41 PM, Justin Erenkrantz wrote:
+static apr_status_t process_request_line(request_rec *r, char *line,
+ int skip_first)
+{
+if (!skip_first (r-the_request == NULL)) {
+/* This is the first line of the request */
+
On 1/3/06, Brian Pane [EMAIL PROTECTED] wrote:
Yeah, setting r-status to HTTP_OK is done here solely to make it work
with the existing logic about HTTP_REQUEST_TIME_OUT meaning still
reading the request header.
+1 for of removing the HTTP_REQUEST_TIME_OUT hack. I was trying
to be
On Jan 3, 2006, at 12:02 AM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote:
Now, if you want to tell me that those changes produced a net
performance benefit on prefork (and thus are applicable to other
MPMs),
then I am all ears. I am
Roy T. Fielding wrote:
Alternatively, rewrite the server to remove all MPMs other than
event and then show that the new server is better than our existing
server, and we can adopt that for 3.0.
Well that's a bit silly, leave the others for those who must have an entirely
non-threaded server
On Dec 31, 2005, at 9:55 PM, Brian Pane wrote:
On Dec 31, 2005, at 6:50 PM, Roy T. Fielding wrote:
The nonblocking yield should happen inside ap_rgetline (or its
replacement), not in the calling routine. The thread has nothing
to do until that call is finished or it times out.
On the
On Jan 2, 2006, at 11:52 AM, Roy T. Fielding wrote:
It would be feasible to build up the pending request in a structure
other than the request_rec, so that ap_read_async_request() can
operate on, say, an ap_partial_request_t instead of a request_rec.
My preference so far, though, has been to
On Jan 2, 2006, at 1:37 PM, Brian Pane wrote:
Significantly faster than prefork has never been a litmus test for
assessing new features, and I'm -1 for adding it now. A reasonable
technical metric for validating the async changes would significantly
more scalable than the 2.2 Event MPM or
On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote:
On Jan 2, 2006, at 1:37 PM, Brian Pane wrote:
Significantly faster than prefork has never been a litmus test for
assessing new features, and I'm -1 for adding it now. A reasonable
technical metric for validating the async changes would
On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote:
Now, if you want to tell me that those changes produced a net
performance benefit on prefork (and thus are applicable to other
MPMs),
then I am all ears. I am easily convinced by comparative performance
figures when the comparison is
It seems to me (catching up on my vacation Email) that the issues can
be resolved by simply reverting the patches on trunk while maintaining
development on the async branch. Certainly one reason for such
branches is to allow for sideline development without affecting
the main development branch
Comments inline.
--On December 31, 2005 11:45:14 PM + [EMAIL PROTECTED] wrote:
= --- httpd/httpd/trunk/include/httpd.h (original)
+++ httpd/httpd/trunk/include/httpd.h Sat Dec 31 15:45:11 2005
@@ -967,6 +967,16 @@
/** A flag to determine if the eos bucket has been sent yet */
On Dec 31, 2005, at 3:45 PM, [EMAIL PROTECTED] wrote:
Author: brianp
Date: Sat Dec 31 15:45:11 2005
New Revision: 360461
URL: http://svn.apache.org/viewcvs?rev=360461view=rev
Log:
Refactoring of ap_read_request() to store partial request state
in the request rec. The point of this is to allow
On Dec 31, 2005, at 6:50 PM, Roy T. Fielding wrote:
The nonblocking yield should happen inside ap_rgetline (or its
replacement), not in the calling routine. The thread has nothing
to do until that call is finished or it times out.
On the contrary, the thread has some very important work to
16 matches
Mail list logo
