You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1999/02/17 05:13:53 UTC

Re: cvs commit: apache-apr/pthreads/src/main http_main.c

It really sucks you guys have to rediscover all this stuff I did for
apache-nspr. 

Stupid license problems. 

Grr. 

Dean

On 17 Feb 1999 manoj@hyperreal.org wrote:

> manoj       99/02/16 16:01:54
> 
>   Modified:    pthreads/src/main http_main.c
>   Log:
>   Eep. ptrans existed in the process scope. Now there is one ptrans per
>   thread, and it is sub-pooled off the correct "super-pool" now. This
>   fixes some very confusing coredumps, which were confusing because there
>   were still coredumps before the original ptrans patch, they were just
>   caused by the lack of ptrans.

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.

bhyde@pobox.com wrote:
> 
> The real question to ask ... Do we support backward compatiblity for existing
> modules?

This question is (and has been) asked in the 2.0 STATUS file.  The answers
of those who bothered to answer show an even split of opinion. :-)
-- 
#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://WWW.Dummies.Com/

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Christof Damian <ch...@mediaconsult.com>.

Ryan Bloom wrote:
> 
> I agree with Jim, that we need to support older modules from A1.3, but I
> am having a hard time figuring out how to do this.  The only solution I
> can think of off the top of my head, is to offer a new module, that
> basically passes requests off to process-based modules, and then accepts
> the data back from them.  This module would need to interface with another
> daemon that actually runs the modules, and this will be a performance hit.
> 

Don't we have this module and this server allready ? The module is
mod_proxy and the server is Apache 1.3.

christof
-- 
Christof Damian                [ we are looking for perl and linux
Technical Director               programmers, more information @
http://mediaconsult.com/         http://mediaconsult.com/wanted ]

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Christof Damian <ch...@mediaconsult.com>.

Greg Stein wrote:
> 
> Ryan Bloom wrote:
> > ...
> > I agree with Jim, that we need to support older modules from A1.3, but I
> > am having a hard time figuring out how to do this.  The only solution I
> > can think of off the top of my head, is to offer a new module, that
> > basically passes requests off to process-based modules, and then accepts
> > the data back from them.  This module would need to interface with another
> > daemon that actually runs the modules, and this will be a performance hit.
> 
> This seems a bit complicated. Why can't you simply say, "if you want to
> run an old module, then set the per-process thread count to 1."
> 
> If people want to stick with legacy code, then they can stick with a
> legacy style of operation. Apache will certainly continue to work for
> them, although they won't see some of the benefits until they update
> their module or obsolete its usage.

If that is the case and the other solution would be to have a
"module-server", then why not tell the people with legacy modules to
run 1.3, which is probably best suited for runing 1.3 modules. And it
is a working solution, while creating a new "module-server" will have
new errors and incompabilities with old modules.

christof
-- 
Christof Damian                [ we are looking for perl and linux
Technical Director               programmers, more information @
http://mediaconsult.com/         http://mediaconsult.com/wanted ]

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Greg Stein <gs...@lyra.org>.

Ryan Bloom wrote:
> ...
> I agree with Jim, that we need to support older modules from A1.3, but I
> am having a hard time figuring out how to do this.  The only solution I
> can think of off the top of my head, is to offer a new module, that
> basically passes requests off to process-based modules, and then accepts
> the data back from them.  This module would need to interface with another
> daemon that actually runs the modules, and this will be a performance hit.

This seems a bit complicated. Why can't you simply say, "if you want to
run an old module, then set the per-process thread count to 1."

If people want to stick with legacy code, then they can stick with a
legacy style of operation. Apache will certainly continue to work for
them, although they won't see some of the benefits until they update
their module or obsolete its usage.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Ryan Bloom <rb...@raleigh.ibm.com>.

On Thu, 18 Mar 1999 bhyde@pobox.com wrote:

> Manoj Kasichainula writes:
> > Also, since (AFAIK) NSPR provides a thread layer (user or system) on
> > every platform it supports, do we even need to bother with coding for
> > the case where we don't have threads available? We could just make sure
> > that we allow for the use of user threads throughout.
> 
> Most apache modules are not going to work in a threaded server without
> reimplementation.  Those projects are hard for three reasons.  The original
> module authors have moved on.  The 3rd party libraries that these modules maybe
> bridging to or leveraging probably don't support threads reliably if at all.
> The learning curve for threaded module writing is bumpy.  It will make it very
> hard for people to switch to A2 if we require them to adopt threads at the 
> same time.
> 
> The real question to ask ... Do we support backward compatiblity for existing
> modules?

I'll address this as best I can.  I have done some testing on the Apache
modules that are included in the base ditribution, and the majority of
them did work in a threaded environment.  The reason for this, is that
they had to work on Windows.  Those that weren't thread-safe we are in the
middle of fixing.  (Yes, I will post to the STATUS file wich are and
aren't when I get the chance).  So for the distributed modules, this is
really a no-op.

The problem is this is most likely not the case for third-party modules.
Any that have implementations on windows should be very easy to port to a
threaded server on any other platform.

I agree with Jim, that we need to support older modules from A1.3, but I
am having a hard time figuring out how to do this.  The only solution I
can think of off the top of my head, is to offer a new module, that
basically passes requests off to process-based modules, and then accepts
the data back from them.  This module would need to interface with another
daemon that actually runs the modules, and this will be a performance hit.

I don't really love this idea, but it wouldn't be too hard to implement,
because all of the code is written.  This also begs the question, how many
of the back-end server do we start?  One per thread (NO), One per child
process (My vote), or one for the whole server(probably not enough)?

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by bh...@pobox.com.

Manoj Kasichainula writes:
> Also, since (AFAIK) NSPR provides a thread layer (user or system) on
> every platform it supports, do we even need to bother with coding for
> the case where we don't have threads available? We could just make sure
> that we allow for the use of user threads throughout.

Most apache modules are not going to work in a threaded server without
reimplementation.  Those projects are hard for three reasons.  The original
module authors have moved on.  The 3rd party libraries that these modules maybe
bridging to or leveraging probably don't support threads reliably if at all.
The learning curve for threaded module writing is bumpy.  It will make it very
hard for people to switch to A2 if we require them to adopt threads at the 
same time.

The real question to ask ... Do we support backward compatiblity for existing
modules?

   - ben

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Manoj Kasichainula <ma...@raleigh.ibm.com>.

On Wed, Mar 03, 1999 at 02:53:59AM -0800, Brian Behlendorf wrote:
> Likewise, I'm not concerned about whether we use Dean's NSPR port, or wrap
> the existing stuff in apache-apr around NSPR.  Either way we end up at the
> right place.

The possible use of NSPR brings up some interesting questions. First
of all, NSPR works on a certain subset of platforms, and that subset
is probably smaller than that of Apache 1.3. Is it a problem to drop
those platforms, or do we want to port NSPR to them? How much loss in
portability are we willing to give up?

Also, since (AFAIK) NSPR provides a thread layer (user or system) on
every platform it supports, do we even need to bother with coding for
the case where we don't have threads available? We could just make sure
that we allow for the use of user threads throughout.

-- 
Manoj Kasichainula - manojk@raleigh.ibm.com
IBM Apache Development Team

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Bill Stoddard <st...@raleigh.ibm.com>.

Brian Behlendorf wrote:
> 
> On Mon, 1 Mar 1999, Bill Stoddard wrote:
> > Most of what we've done in the past month is not related to the
> > protability layer. If we do decide to go with NSPR, I strongly recommend
> > we NSPR'ize the pthreads port in the apache-apr reporitory. The pthreads
> > port in apache-apr is a functioning hybrid multi-process, multi-threaded
> > server. I'm not too keen on the accept queue, but with some fairly minor
> > changes, we can abstract it out and make it easy and clean to implement
> > other accept algorithms.  We've also been keeping it up to date with the
> > Apache 1.3 tree.
> 
> Likewise, I'm not concerned about whether we use Dean's NSPR port, or wrap
> the existing stuff in apache-apr around NSPR.  Either way we end up at the
> right place.
> 

apache-apr started out with Dean's work (sans the NSPR  calls). What we
have been doing for the last couple of months is build on top of what
Dean has already done. Dean's code implemented a threaded webserver. We
made it a hybrid process/threaded webserver and added back a lot of the
features found in Apache 1.3 (e.g., monitor process to restart failed
children, scoreboard, dynamically adjusting the number of child
processes based on server load, etc.).

I spent a week or so replicating Dean's work using pthreads out of a
current Apache 1.3 code tree. Without Dean's work as a guide, it would
have taken MUCH longer to establish the working base and we would not be
where we are today with apache-apr. 

Dean deserves a ton of credit, perhaps even most of the credit, for
apache-apr.  

BTW, NSPR has -not- be released under the new NPL (NPL 1.0M?). I think
the plan is to do it sometime toward the end of March. 

-- 
Bill Stoddard
stoddard@raleigh.ibm.com

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Brian Behlendorf <br...@hyperreal.org>.

On Mon, 1 Mar 1999, Bill Stoddard wrote:
> Most of what we've done in the past month is not related to the
> protability layer. If we do decide to go with NSPR, I strongly recommend
> we NSPR'ize the pthreads port in the apache-apr reporitory. The pthreads
> port in apache-apr is a functioning hybrid multi-process, multi-threaded
> server. I'm not too keen on the accept queue, but with some fairly minor
> changes, we can abstract it out and make it easy and clean to implement
> other accept algorithms.  We've also been keeping it up to date with the
> Apache 1.3 tree.

Likewise, I'm not concerned about whether we use Dean's NSPR port, or wrap
the existing stuff in apache-apr around NSPR.  Either way we end up at the
right place.

+1.  :)

	Brian

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Bill Stoddard <st...@raleigh.ibm.com>.

Brian Behlendorf wrote:
> 
> On Fri, 26 Feb 1999, Bill Stoddard wrote:
> > I am way past the point of caring about NSPR. We should use the APR API
> > IMHO. If the new MPL allows, I'm certainly not opposed to using pieces
> > out of NSPR where it makes sense.
> 
> Maybe I really shouldn't speak up about this as my contribution in either
> the APR or NSPR direction has been nil (other than to point Dean at NSPR
> 12 months ago), but...
> 
> It seems that the goal of APR and NSPR is the same: to create a
> portability interface for I/O and threading, primarily, and other random
> pieces of platform-specific functionality.  I seem to recall the reason
> for starting APR was because there was fear that we wouldn't be able to
> use NSPR.  Now that it looks like we can (I don't want to say it's
> definite, but it looks pretty good, and apparently IBM is happy with the
> new MPL), we should IMHO revisit the need for APR.
> 
> I feel like an asshole for suggesting this, because I know the effort IBM
> has been putting into APR.  My main concern is that this problem space, a
> portability layer, is a very unglamorous task, one that really benefits
> from widest usage, and I just don't know if there's enough of an at-large
> development community to support two portability-layer projects equally
> well.
> 
> I certainly don't think that using the NSPR at this point will mean a
> waste of the last month's work - it seems like a lot of the changes were
> things we'd run across anyways, duplicates of Dean's work on NSPR, and
> general threading issues that are independent of this portability layer.
> 
I don't know enough about the NSPR implementation to make a judgement on
whether we should use it or not. However, from a casual reading of the
API, it looks pretty close to what we were trying to accomplish with
APR. It's worth considering if it will help us release Apache 2.0
faster.

Most of what we've done in the past month is not related to the
protability layer. If we do decide to go with NSPR, I strongly recommend
we NSPR'ize the pthreads port in the apache-apr reporitory. The pthreads
port in apache-apr is a functioning hybrid multi-process, multi-threaded
server. I'm not too keen on the accept queue, but with some fairly minor
changes, we can abstract it out and make it easy and clean to implement
other accept algorithms.  We've also been keeping it up to date with the
Apache 1.3 tree.

-- 
Bill Stoddard
stoddard@raleigh.ibm.com

Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Dean Gaudet <dg...@arctic.org>.

I no longer really have a strong opinion either way. 

In fact both ways irk me -- because third party libraries which do
pipe/socket i/o are unuseable in both cases unless the library is ported
to our i/o interface.

Dean

NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)

Posted by Brian Behlendorf <br...@hyperreal.org>.

On Fri, 26 Feb 1999, Bill Stoddard wrote:
> I am way past the point of caring about NSPR. We should use the APR API
> IMHO. If the new MPL allows, I'm certainly not opposed to using pieces
> out of NSPR where it makes sense.

Maybe I really shouldn't speak up about this as my contribution in either
the APR or NSPR direction has been nil (other than to point Dean at NSPR 
12 months ago), but...

It seems that the goal of APR and NSPR is the same: to create a
portability interface for I/O and threading, primarily, and other random
pieces of platform-specific functionality.  I seem to recall the reason
for starting APR was because there was fear that we wouldn't be able to
use NSPR.  Now that it looks like we can (I don't want to say it's
definite, but it looks pretty good, and apparently IBM is happy with the
new MPL), we should IMHO revisit the need for APR.

I feel like an asshole for suggesting this, because I know the effort IBM
has been putting into APR.  My main concern is that this problem space, a
portability layer, is a very unglamorous task, one that really benefits
from widest usage, and I just don't know if there's enough of an at-large
development community to support two portability-layer projects equally
well.

I certainly don't think that using the NSPR at this point will mean a
waste of the last month's work - it seems like a lot of the changes were
things we'd run across anyways, duplicates of Dean's work on NSPR, and
general threading issues that are independent of this portability layer.

And it seems like we have greater challenges than a portability layer we
should be looking at, like

1) How to mitigate the reliability problem with a single-process
multithreaded model (either by going multiprocess, or having logic take
place in separate daemons a la mod_jserv, etc)

2) new configuration syntax

3) how to facilitate kernel-level speedups

etc.  

So I respectfully ask that we as a group reconsider NSPR vs. APR in light
of the license changes.  You can see the new license at
http://www.mozilla.org/NPL/NPL-1.0M.html and an FAQ on it at
http://www.mozilla.org/NPL/NPL-1.0M-FAQ.html .  What's missing from the
NSPR that we'd planned on having in APR?  Would it be more work to get it
in there, or to do it ourselves?  Etc.

My main interest is in trying to prevent duplication of effort.  I do
believe there is a role for competition in open-source; that it's good
there are other web servers, or servlet engines, or page compilation
tools, or *BSD's, etc. out there.  But that only makes sense when there's
enough developers to actively support multiple projects.  I'm not sure
that's the case here.

	Brian