httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: "Strcasecmp problem"
Date Sat, 03 Aug 1996 00:47:19 GMT
  > 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).

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.

On the whole, it seems to involve changing a whole lot less of the
code, and it worked for me almost immediately after I got the kinks
out of the basic I/O, with very little trouble since.  (It's been taking
between 30K and 70K hits a day for me for a couple of months now).
You might want to look it over.

  Of course it
  would have been more intelligent on my side to actually allocate the
  server structure once and then use it between the threads.  But that is
  not possible without altering many of the structures.  My aim was to
  simply get the Apache running on NT and nothing more.

  For example in the structure server_rec there is are two members
  server_rec::pconf
  server_rec::ptrans
  The first item is not problem.

Those aren't in the standard Apache server_rec --- likewise, my
threaded version has no need for them, since all server_recs are
allocated from the single configuration pool.  Only records for
conn_recs and request_recs need thread-particular pools (and they have
them already).  Again, if you hadn't tried (wrongly, IMHO) to
multithread server startup, this simply wouldn't be an issue.

  I think if we were to port the Apache to threads we will have to take a
  look at what the structures do specifically.  

There already is at least one threaded version of Apache which works
fine without any serious changes to the data structures in question.

rst


Mime
View raw message