You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@organic.com> on 1998/02/04 01:35:53 UTC
future plans
At 08:01 AM 2/3/98 -0500, Jim Jagielski wrote:
>To me, it's looking like there is still a lot we could do with 1.3.0.
Indeed.
> 1. We stop development on 1.3 in order to release 1.3.0.
> We focus on 2.0.
I think the problems we've all had regarding 2.0 development have been
around having much larger plans than any of us can reasonably do in a given
amount of time.
What if we said that the only major advances we *needed* to have in 2.0 was
multithreading. A new API would be nice (we can get partway there with
some extra phases), as well layered IO or a new config language, but
ultimately the most pressing issue in apache compared to other servers is
the multithreading issue. The hard part will be coming up with a portable
threading interface, something which runs in front of pthreads, or native
threads, or even a multi-process emulation of threading. The core code
should be mostly thread safe particularly since the NT port is
multithreaded anyways.
Since threading is pretty closely tied with IO it might make sense to also
do the IO stuff we've talked about at the same time... but I really do see
everyone's plans for 2.0 being much larger than I think any of us will be
able to chew anytime soon.
If someone comes up with a proposed threading interface spec, and backs it
with pthreads, that'll get us a huge chunk of the way there; other
threading models can be implemented as 2.0 rolls through alpha. The basic
idea, though, is to lower our aims for what 2.0 will include.
comments?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
Re: future plans
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 5 Feb 1998, Ben Laurie wrote:
> I'm not convinced its as simple as this. For example, if I avoid calling
> things by inlining (== big) then is that really slower?
It can be. Especially on x86 processors -- there just aren't enough
registers to take complete advantage of inlined code. Alan Cox has shown
a linux kernel that's faster by not inlining the functions which do copies
from user to kernel and vice versa. On risc processors you can usually
eat up inlined code by register renaming and filling in more delay slots.
> Can we quantify what this actually means, please? Like, a list of
> platforms, and what their C++ support is would be good. Also a list of
> platforms we care about (in the 2.0 timeframe. So anything with year
> 2000 problems is out :-).
The only platforms I'm personally interested in are Unix based (ok ok
POSIX) and are still supported by their vendor. If we leave the
unsupported ones behind I won't mind. They'll still have Apache 1.x.
> > Then I'm +0 on using C++.
>
> Wow! I'm making progress!
:)
Dean
Re: future plans
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Thu, 5 Feb 1998, Ben Laurie wrote:
>
> > Unfortunately, I find it hard to get motivated about API redesign since
> > this group consistently rejects the only _sensible_ way forward (i.e.
> > C++), on grounds that are becoming increasingly shaky. I do sympathize
> > with those who don't yet know C++ well (or at all) but hell, guys,
> > you've got to start somewhere, right?
>
> If we can maintain the mentality that "lean is good", which means that C++
> weenies do not get to link in 5 zillion class libraries just because they
> don't want to code up a linked list or some other silliness like that. I'm
> not going to be happy with an apache that's twice its current size. (This
> is where theory and reality collide -- small == less instruction cache
> footprint == faster.)
I'm not convinced its as simple as this. For example, if I avoid calling
things by inlining (== big) then is that really slower?
> And we can avoid the really broken "features" of C++, like operator
> overloading (yeah sure, theoretically a cool thing, but try debugging a
> program that (ab)uses this "feature").
I'm not saying this is going to be a completely painless process. Given
that major code bloat and obscurity is an easy-to-achieve side effect of
careless C++, we need to keep an eye on these things, but dismissing
whole language features out of hand because of a bad experience is
really taking it a bit far.
> And we can be happy that we're not losing platforms that we care about.
> (In order to decide this we have to decide what intersection of "features"
> we're going to use.)
Can we quantify what this actually means, please? Like, a list of
platforms, and what their C++ support is would be good. Also a list of
platforms we care about (in the 2.0 timeframe. So anything with year
2000 problems is out :-).
> Then I'm +0 on using C++.
Wow! I'm making progress!
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: future plans
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 5 Feb 1998, Ben Laurie wrote:
> Unfortunately, I find it hard to get motivated about API redesign since
> this group consistently rejects the only _sensible_ way forward (i.e.
> C++), on grounds that are becoming increasingly shaky. I do sympathize
> with those who don't yet know C++ well (or at all) but hell, guys,
> you've got to start somewhere, right?
If we can maintain the mentality that "lean is good", which means that C++
weenies do not get to link in 5 zillion class libraries just because they
don't want to code up a linked list or some other silliness like that. I'm
not going to be happy with an apache that's twice its current size. (This
is where theory and reality collide -- small == less instruction cache
footprint == faster.)
And we can avoid the really broken "features" of C++, like operator
overloading (yeah sure, theoretically a cool thing, but try debugging a
program that (ab)uses this "feature").
And we can be happy that we're not losing platforms that we care about.
(In order to decide this we have to decide what intersection of "features"
we're going to use.)
Then I'm +0 on using C++.
Dean
Re: future plans
Posted by Ben Laurie <be...@algroup.co.uk>.
Brian Behlendorf wrote:
>
> At 08:01 AM 2/3/98 -0500, Jim Jagielski wrote:
> >To me, it's looking like there is still a lot we could do with 1.3.0.
>
> Indeed.
>
> > 1. We stop development on 1.3 in order to release 1.3.0.
> > We focus on 2.0.
>
> I think the problems we've all had regarding 2.0 development have been
> around having much larger plans than any of us can reasonably do in a given
> amount of time.
>
> What if we said that the only major advances we *needed* to have in 2.0 was
> multithreading. A new API would be nice (we can get partway there with
> some extra phases), as well layered IO or a new config language, but
> ultimately the most pressing issue in apache compared to other servers is
> the multithreading issue. The hard part will be coming up with a portable
> threading interface, something which runs in front of pthreads, or native
> threads, or even a multi-process emulation of threading. The core code
> should be mostly thread safe particularly since the NT port is
> multithreaded anyways.
>
> Since threading is pretty closely tied with IO it might make sense to also
> do the IO stuff we've talked about at the same time... but I really do see
> everyone's plans for 2.0 being much larger than I think any of us will be
> able to chew anytime soon.
>
> If someone comes up with a proposed threading interface spec, and backs it
> with pthreads, that'll get us a huge chunk of the way there; other
> threading models can be implemented as 2.0 rolls through alpha. The basic
> idea, though, is to lower our aims for what 2.0 will include.
>
> comments?
This makes a lot of sense to me. Threading + I/O is what we really need,
though a radical API redesign wouldn't be such a bad thing.
Unfortunately, I find it hard to get motivated about API redesign since
this group consistently rejects the only _sensible_ way forward (i.e.
C++), on grounds that are becoming increasingly shaky. I do sympathize
with those who don't yet know C++ well (or at all) but hell, guys,
you've got to start somewhere, right?
Now that STL and friends are with us, and templates are more-or-less
universally supported, the benefits of C++ are becoming so vast they are
hard to ignore. Apache is now the _only_ program I spend any significant
amount of time on that is still in C. And for those who still want a C
API, I really can't see that there's a problem (though it is likely to
be rather clunky in comparison to a C++ one).
So, I'd support 2.0 (or 1.4) being threads+I/O, and 3.0 (or 2.0) being
C++ and radical API redesign.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache