httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)
Date Thu, 18 Mar 1999 14:21:06 GMT

On Thu, 18 Mar 1999 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 Bloom
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.	

View raw message