httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: PLEASE READ: Filter I/O
Date Thu, 22 Jun 2000 22:12:23 GMT

> > Although I can't make any well reasoned arguments against this patch, I
> > can without a doubt make one against the design.  The recursive nature of
> > your design will slow this server to a crawl on some platforms.  Take a
> > look at the Sparc architecture.  This architecture uses register windows,
> > and these fall down when making recursive calls.
> I really don't know how to respond to this. This is not reality. Can you
> corroborate this position with any evidence?
> Entering a function multiple times on the same thread of execution is simply
> NOT a problem.


                                             Register Windows

       For rapid context switch 
       Fixed window size rarely matches 
       Four special-purpose sets/window 
       Many registers sit idle at any time 
       Only good for shallow call stack -- not sufficient for recursion 
       Subroutine calls can force memory accesses in order to spill a window


It seems to me that unless we can keep plenty of values in registers
across a procedure call, then there's no point in using register
windows at all -- in fact, with recursive programs that don't keep
most of the registers full, register windows will make matters much

Need more?  I grabbed these by doing a quick search with Google for
register windows and recursion.

> At this point, I am at a quandary. I can roll back the
> check_first_conn_error() thing, although with some difficulty because of
> later commits. I'm willing to do so, but it seems that I've addressed your
> technical justifications for the veto. It would be helpful if you could do
> one of two things: rescind the veto (easiest for all involved), or you could
> explain any further issues (i.e. whether your original technical issue still
> exists, or you have further issues).

I do not expect you to roll back the change.  At this point, I am
continuing with development of 2.0, in both filtered I/O and other
areas.  I will continue to make my patch work with head.

> > These "common" things that you want to change have VERY
> > different solutions based on which scheme is chosen finally.
> I understand and have been choosing changes that both approaches will need.

Both approaches need solutions to these problems, but the proper fix for
the problems is very specific to which approach we take.  This is my

> Sigh. This is a basic lack of trust, which is normally implied by the
> commit-then-review model. I will do RTC, but only under protest.

This is not a lack of trust.  This is a simple desire to not have to
continue to hack my patch to work with HEAD.  At this point, I care very
little about any of this to be incredibly honest.  I am doing other work,
and I will most likely avoid filtered I/O completely until your patch is

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message