httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Gross" <>
Subject Re: "Strcasecmp problem"
Date Sat, 03 Aug 1996 01:41:14 GMT
> From: Robert S. Thau <>
> To:
> Subject: Re: "Strcasecmp problem"
> Date: samedi, 3. ao{t 1996 02:47
>   > So, the only possible conflict is if two threads are calling
>   > at the same time.  But that simply shouldn't be happening --- it
>   > doesn't happen in stock Apache.  Even if you have multithreaded
>   > *startup*, for some unaccountable reason, why are you initializing
>   > *same module* more than once?
>   > 
>   The problem is as follows.  When I originally looked at the source I
>   not know it very well and am still struggling to understand it
>   The code was implemented that each thread would be its own
>   This mimics the behaviour of the process oriented style.
> It also involves massive, thoroughly inelegant, redundant effort at
> server startup, which you would do well to eliminate anyway.  It also
> assumes that you know the correct number of threads to run at server
> startup --- the scoreboard mechanism was added to the process-pool
> version of Apache precisely because this number is actually quite
> hard to accurately guess.  (Too low, and clients can't get in because
> all the threads are busy; too high, and you're wasting resources badly).
> BTW, as you may not be aware, I've already implemented a pre-alpha
> version of Apache for Unix (you can get a fairly recent snapshot from
> if you're
> It uses a rather different style of processing, which is much more in
> with what the code was originally designed to support (yes, it was
> with threads in mind).
Have downloaded and looked at it.
> Basically, configuration is run single-threaded; subsequently, new
> threads are created and allocated to requests as those requests are
> accepted.  With that model, relatively little of the code (in
> particular, almost nothing in the mod_*.c files, and relatively little
> outside of buff.* and http_main.c in the server core) has to change
> though a few files (http_main.c, buff.*) are very substantial rewrites.
I have to admit I liked what I saw when I looked at the threaded version
of the HTTP server.  However, I think that we should adopt an approach
that someone mentioned to me in another email.  We should begin to split
Apache into operating system dependent sections. I would be more than
happy to port your threaded server to NT, but the fear I see, is that I
will simply delete huge sections of code.  Many calls could be replaced by
native methods of the OS.  If we took an approach where by we created a
hardware layer that moves all calls to a neutral API then porting would be
simple.  Only the hardware layer would need porting.  Then there is always
the solution of using Java.

Christian Gross
Phone 41.1.492.7827
Fax 41.1.492.7757

View raw message