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: mod_perl_fast anyone?
Date Thu, 09 May 1996 08:00:02 GMT
I have plenty of thoughts on this... more than I have time to write up
immediately, unfortunately.  One thing which I'm interested in, however,
is how these things would get along with threading... 

To reiterate, I'm working on a threaded version of Apache.  Right now,
I don't think it's in distributable condition basically because of some
problems of unknown origin dealing with Mac clients (probably, but not
definitely, related to their problems in handling a normal TCP close,
which my http_main code tries to arrange for).  The threads are non-
preemptive, which means that a thread only gives up the processor when
it explicitly chooses to do so (and if it blocks in the meantime, no
other thread in the same process can run).  Needless to say, the
rprintf(), rputs(), etc., routines *do* give up the processor if the
kernel's buffers for the client connection are full.

So, my first thought is to wonder exactly how either mod_perl would get
along in this environment, and what the threading package itself could
do to help.  (In particular, what Perl compilation options would make
a difference, and would it help if the threads package could be told
to save and restore the values of a few global variables across context
switches)?

I also have some thoughts on the style of language-integration issue...
basically, I think that if we had a semi-decent way of caching config
information, and invalidating pieces of it without doing a full-scale
server restart, a lot of neat things *might* come out in the wash.
But those thoughts are half-baked, and further elaboration will have
to wait at *least* till I get back from Paris...

rst

Mime
View raw message