httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Gross" <cgr...@eusoft.com>
Subject Re: "Strcasecmp problem"
Date Sat, 03 Aug 1996 01:41:14 GMT
----------
> From: Robert S. Thau <rst@ai.mit.edu>
> To: new-httpd@hyperreal.com
> Subject: Re: "Strcasecmp problem"
> Date: samedi, 3. ao{t 1996 02:47
> 
>   > So, the only possible conflict is if two threads are calling
init_mime
>   > at the same time.  But that simply shouldn't be happening --- it
certainly
>   > doesn't happen in stock Apache.  Even if you have multithreaded
server
>   > *startup*, for some unaccountable reason, why are you initializing
the
>   > *same module* more than once?
>   > 
>   The problem is as follows.  When I originally looked at the source I
did
>   not know it very well and am still struggling to understand it
properly. 
>   The code was implemented that each thread would be its own
mini-server. 
>   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
threaded
> version of Apache for Unix (you can get a fairly recent snapshot from
> ftp://ftp.ai.mit.edu/pub/users/rst/apache-XX.tar.gz if you're
interested).
> It uses a rather different style of processing, which is much more in
line
> with what the code was originally designed to support (yes, it was
designed
> 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
much,
> 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
euSOFT
Phone 41.1.492.7827
Fax 41.1.492.7757
http://www.eusoft.com
cgross@eusoft.com

Mime
View raw message