Re: [PATCH] WIN64: httpd API changes
On Thu, Oct 07, 2004 at 04:52:28PM -0400, Allan Edwards wrote: > This set of changes gets rid of most of the libhttpd > 64bit warnings on Windows at the cost of several httpd > API changes. I defined AP_INT_TRUNC_CAST for use where > there are size mismatches with APR API's (those APR > API's will need to be updated in APR 2.0) Again I think the use of the macro is really ugly. > -AP_DECLARE(int) ap_rputs(const char *str, request_rec *r); > +AP_DECLARE(apr_size_t) ap_rputs(const char *str, request_rec *r); The ap_r* changes are not safe: these functions return negative values on error. Each and every int->size_t conversion needs to be carefully checked for this kind of issue. joe
Re: segfault in worker mpm
Stas Bekman wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
I did some binary search and found that:
mp2-20040922 - no core
mp2-20040923 - core
So we need to diff these two checkouts...
For a start, I've got these changes exposed in between those 2 dates:
http://www.apache.org/~gozer/mp2/2004-09-22+23/
That's a handy output. I'll try applying each separately to see which
one was the trigger.
For some reason, your output doesn't match mine. for me the difference
between 22nd and 23 starts from 3428 [1] and goes into the next day,
which is not included in your output:
[1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch
but I think I'm getting there
It seems that this patch applied as reversed to the checkout from 23 Sept
resolves the segfault in t/filter/both_str_req_add.t. As you can see all
the changes are in creating new Vhosts entries.
However this doesn't resolve the current cvs problem, as I think there
were more entries added after Sept 23th, that cause the latest one.
diff -ru --exclude=CVS t/hooks/TestHooks/init.pm t/hooks/TestHooks/init.pm
--- t/hooks/TestHooks/init.pm 2003-08-11 16:34:22.0 -0400
+++ t/hooks/TestHooks/init.pm 2004-09-22 21:44:10.0 -0400
@@ -54,11 +54,15 @@
1;
__DATA__
-PerlInitHandler TestHooks::init::second
-
+
+
PerlModule TestHooks::init
PerlInitHandler TestHooks::init::first
-
-PerlResponseHandler TestHooks::init
-PerlResponseHandler TestHooks::init::response
-SetHandler modperl
+
+PerlInitHandler TestHooks::init::second
+PerlResponseHandler TestHooks::init
+PerlResponseHandler TestHooks::init::response
+SetHandler modperl
+
+
+
diff -ru --exclude=CVS t/response/TestUser/rewrite.pm
t/response/TestUser/rewrite.pm
--- t/response/TestUser/rewrite.pm 2004-07-09 17:52:49.0 -0400
+++ t/response/TestUser/rewrite.pm 2004-09-22 21:44:11.0 -0400
@@ -62,6 +62,7 @@
1;
__END__
+
PerlModule TestUser::rewrite
PerlTransHandlerTestUser::rewrite::trans
PerlMapToStorageHandler TestUser::rewrite::map2storage
@@ -69,5 +70,6 @@
SetHandler modperl
PerlResponseHandler TestUser::rewrite::response
+
diff -ru --exclude=CVS t/modules/proxy.t t/modules/proxy.t
--- t/modules/proxy.t 2004-08-03 12:16:22.0 -0400
+++ t/modules/proxy.t 2004-09-22 21:44:11.0 -0400
@@ -3,14 +3,19 @@
use Apache::Test;
use Apache::TestUtil;
-
use Apache::TestRequest;
-my $location = "/TestModules__proxy";
+my $module = 'TestModules::proxy';
+
+Apache::TestRequest::module($module);
+my $path = Apache::TestRequest::module2path($module);
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");
plan tests => 1, (need_module('proxy') &&
need_access);
my $expected = "ok";
-my $received = GET_BODY_ASSERT $location;
+my $received = GET_BODY_ASSERT "http://$hostport/$path";;;
ok t_cmp($received, $expected, "internally proxified request");
diff -ru --exclude=CVS t/response/TestModules/proxy.pm
t/response/TestModules/proxy.pm
--- t/response/TestModules/proxy.pm 2004-07-09 04:01:21.0 -0400
+++ t/response/TestModules/proxy.pm 2004-09-22 21:44:11.0 -0400
@@ -43,6 +43,7 @@
1;
__END__
+
http://@servername@:@port@/*>
@@ -59,5 +60,6 @@
PerlResponseHandler TestModules::proxy::response
+
diff -ru --exclude=CVS t/hooks/TestHooks/trans.pm t/hooks/TestHooks/trans.pm
--- t/hooks/TestHooks/trans.pm 2003-04-18 02:18:58.0 -0400
+++ t/hooks/TestHooks/trans.pm 2004-09-22 21:44:11.0 -0400
@@ -37,5 +37,12 @@
1;
__DATA__
-PerlResponseHandler Apache::TestHandler::ok1
-SetHandler modperl
+
+
+PerlTransHandler TestHooks::trans
+
+PerlResponseHandler Apache::TestHandler::ok1
+SetHandler modperl
+
+
+
diff -ru --exclude=CVS t/hooks/trans.t t/hooks/trans.t
--- t/hooks/trans.t 2003-03-31 23:39:30.0 -0500
+++ t/hooks/trans.t 2004-09-22 21:44:10.0 -0400
@@ -8,15 +8,20 @@
use Apache2 ();
use Apache::Const ':common';
+my $module = 'TestHooks::trans';
+Apache::TestRequest::module($module);
+my $path = Apache::TestRequest::module2path($module);
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");
+
plan tests => 3;
t_client_log_error_is_expected();
-ok GET_RC('/nope') == NOT_FOUND;
-
-my $module = '/TestHooks/trans.pm';
+ok t_cmp GET_RC("http://$hostport/nope";), NOT_FOUND;
-my $body = GET_BODY $module;
+my $body = GET_BODY "http://$hostport/TestHooks/trans.pm";;
-ok $body =~ /package TestHooks::trans/;
+ok $body =~ /package $module/;
-ok GET_OK '/phooey';
+ok GET_OK "http://$hostport/phooey";;
--
__
Stas BekmanJAm
Re: segfault in worker mpm
Stas Bekman wrote: Philippe M. Chiasson wrote: Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ That's a handy output. I'll try applying each separately to see which one was the trigger. For some reason, your output doesn't match mine. for me the difference between 22nd and 23 starts from 3428 [1] and goes into the next day, which is not included in your output: [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch but I think I'm getting there -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in worker mpm
Philippe M. Chiasson wrote: Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ That's a handy output. I'll try applying each separately to see which one was the trigger. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: PATCH to use apr-iconv
--On Tuesday, October 5, 2004 10:56 AM +0200 jean-frederic clere <[EMAIL PROTECTED]> wrote: I have now moved all the logic to apr-util. Find enclosed the new patch. To get it working checkout apr-iconv in srclib and add "--with-iconv=`pwd`/srclib/apr-iconv". More comments? Besides the fact that this conversation belongs on [EMAIL PROTECTED], I think the ../apr-iconv directory should only be configured when it is present *and* a suitable system iconv() isn't found. This would match the behavior of our bundled expat sources. -- justin
Re: mod_disk_cache directives naming convention
On Thu, Oct 07, 2004 at 12:12:57PM -0700, Justin Erenkrantz wrote: > --On Thursday, October 7, 2004 12:13 PM -0600 Jean-Jacques Clar > <[EMAIL PROTECTED]> wrote: > > >I won't probably agree if we use 'Waboozle', and I suggest that the > >description > >should with the name of the module like MemCache* and DiskCache* to > >make it easier for related directives to be grouped together (sorted). > > I'd really prefer for all caching directives to be under Cache* so that the > alphabetical ordering of the directives that we generate in our docs group > them together. Using MemCache* and DiskCache* instead of CacheMem* and > CacheDisk* sort of blow that away. +1 directives should be grouped into module namespace prefixes whenever possible Not only will things sort together in web pages, but this is more intuitive for many non-English speakers since many languages put the adjectives after the noun, i.e. the subdescription after the description. Cheers, Glenn
RE: Bye bye welcome page
On Thu, 2004-10-07 at 12:08, John Rowe wrote: > > > If I was a newbie, and I saw a page that says `it worked`, my immediate > > > reaction would be `what worked?` and I would start asking the exact > > > questions we`re trying to stop people from asking. > > > > We can always go with simply displaying a meaningless word like 'Waboozle'. > > And so the madness begins again.. [...] I do hope everyone realizes I was kidding. The only thing we have to do is agree on a concise and clear message. I don't think it is we are likely to reach concensus on proze like the welcome page. Other than lazy concensus that is. FWIW, I'm fine with Joshua's suggestion. Sander
[PATCH] WIN64: httpd API changes
This set of changes gets rid of most of the libhttpd 64bit warnings on Windows at the cost of several httpd API changes. I defined AP_INT_TRUNC_CAST for use where there are size mismatches with APR API's (those APR API's will need to be updated in APR 2.0) Comments before I commit? Allan - Index: include/ap_mmn.h === RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v retrieving revision 1.69 diff -U3 -r1.69 ap_mmn.h --- include/ap_mmn.h4 Jun 2004 22:40:46 - 1.69 +++ include/ap_mmn.h7 Oct 2004 20:48:55 - @@ -84,14 +84,15 @@ * changed ap_add_module, ap_add_loaded_module, * ap_setup_prelinked_modules, ap_process_resource_config * 20040425.1 (2.1.0-dev) Added ap_module_symbol_t and ap_prelinked_module_symbols + * 20041007 (2.1.0-dev) API changes to clean up 64bit compiles */ #define MODULE_MAGIC_COOKIE 0x41503230UL /* "AP20" */ #ifndef MODULE_MAGIC_NUMBER_MAJOR -#define MODULE_MAGIC_NUMBER_MAJOR 20040425 +#define MODULE_MAGIC_NUMBER_MAJOR 20041007 #endif -#define MODULE_MAGIC_NUMBER_MINOR 1 /* 0...n */ +#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */ /** * Determine if the server's current MODULE_MAGIC_NUMBER is at least a Index: include/http_protocol.h === RCS file: /home/cvs/httpd-2.0/include/http_protocol.h,v retrieving revision 1.92 diff -U3 -r1.92 http_protocol.h --- include/http_protocol.h 18 Jul 2004 20:06:38 - 1.92 +++ include/http_protocol.h 7 Oct 2004 20:48:55 - @@ -340,7 +340,7 @@ * @return The number of bytes sent * @deffunc int ap_rputs(const char *str, request_rec *r) */ -AP_DECLARE(int) ap_rputs(const char *str, request_rec *r); +AP_DECLARE(apr_size_t) ap_rputs(const char *str, request_rec *r); /** * Write a buffer for the current request @@ -359,7 +359,7 @@ * @return The number of bytes sent * @deffunc int ap_rvputs(request_rec *r, ...) */ -AP_DECLARE_NONSTD(int) ap_rvputs(request_rec *r,...); +AP_DECLARE_NONSTD(apr_size_t) ap_rvputs(request_rec *r,...); /** * Output data to the client in a printf format @@ -369,7 +369,7 @@ * @return The number of bytes sent * @deffunc int ap_vrprintf(request_rec *r, const char *fmt, va_list vlist) */ -AP_DECLARE(int) ap_vrprintf(request_rec *r, const char *fmt, va_list vlist); +AP_DECLARE(apr_size_t) ap_vrprintf(request_rec *r, const char *fmt, va_list vlist); /** * Output data to the client in a printf format @@ -379,7 +379,7 @@ * @return The number of bytes sent * @deffunc int ap_rprintf(request_rec *r, const char *fmt, ...) */ -AP_DECLARE_NONSTD(int) ap_rprintf(request_rec *r, const char *fmt,...) +AP_DECLARE_NONSTD(apr_size_t) ap_rprintf(request_rec *r, const char *fmt,...) __attribute__((format(printf,2,3))); /** * Flush all of the data for the current request to the client @@ -445,7 +445,7 @@ * if EOF, or -1 if there was an error * @deffunc long ap_get_client_block(request_rec *r, char *buffer, apr_size_t bufsiz) */ -AP_DECLARE(long) ap_get_client_block(request_rec *r, char *buffer, apr_size_t bufsiz); +AP_DECLARE(apr_size_t) ap_get_client_block(request_rec *r, char *buffer, apr_size_t bufsiz); /** * In HTTP/1.1, any method can have a body. However, most GET handlers Index: include/httpd.h === RCS file: /home/cvs/httpd-2.0/include/httpd.h,v retrieving revision 1.212 diff -U3 -r1.212 httpd.h --- include/httpd.h 12 Aug 2004 05:22:59 - 1.212 +++ include/httpd.h 7 Oct 2004 20:48:55 - @@ -1091,7 +1091,7 @@ /** Pathname for ServerPath */ const char *path; /** Length of path */ -int pathlen; +apr_size_t pathlen; /** Normal names for ServerAlias servers */ apr_array_header_t *names; @@ -1244,7 +1244,7 @@ * address of field is shifted to the next non-comma, non-whitespace * character. len is the length of the item excluding any beginning whitespace. */ -AP_DECLARE(const char *) ap_size_list_item(const char **field, int *len); +AP_DECLARE(const char *) ap_size_list_item(const char **field, apr_size_t *len); /** * Retrieve an HTTP header field list item, as separated by a comma, @@ -1587,7 +1587,7 @@ * @param c The character to search for * @return The index of the first occurrence of c in str */ -AP_DECLARE(int) ap_ind(const char *str, char c); /* Sigh... */ +AP_DECLARE(apr_size_t) ap_ind(const char *str, char c);/* Sigh... */ /** * Search a string from right to left for the first occurrence of a @@ -1596,7 +1596,7 @@ * @param c The character to search for * @return The index of the first occurrence of c in str */ -AP_DECLARE(int) ap_rind(const char *str, char c); +AP_DECLARE(apr_size_t) ap_rind(const char *str, char c); /** * Gi
Re: Bug: Apache hangs if script invokes fork/waitpid
Jeff Trawick wrote: I think there needs to be a mod_fork which provides a more general purpose daemon than that used by mod_cgid, and some Apache API will know whether or not to send a request over there. This preserves the goal of having fork() called only by single-threaded processes so that all manner of pain is avoided. Big +1 from me in concept. I am not sure how to do the implementation best. mod_cgid doesn't really 'fork' in the sense most programs do, its mostly just starting up a cgi process -- from an executable on the file system. This seems drastically different from the requirements of a generic fork(). Any thoughts on how you would want to implement this in a generic manner for any call from anywhere for any module? -Paul Querna
Re: Bug: Apache hangs if script invokes fork/waitpid
On Wed, 6 Oct 2004 11:01:23 -0700, Naik, Roshan <[EMAIL PROTECTED]> wrote: > The Problem: > --- > I notice Apache 2(worker mpm) is not able to correctly handle > a fork/waitpid invoked by a script used with mod_perl. >From Ulrich Drepper: "No threaded programs must use anything but _exit or exec after fork." Perhaps a tiny bit harsh? What if you fork a copy of a mutex used by some third-party Apache module? That module would need to be using pthread_atfork() to make sure ownership is preserved properly. Apache/APR certainly doesn't do it with its mutexes. I think there needs to be a mod_fork which provides a more general purpose daemon than that used by mod_cgid, and some Apache API will know whether or not to send a request over there. This preserves the goal of having fork() called only by single-threaded processes so that all manner of pain is avoided.
Re: mod_disk_cache directives naming convention
--On Thursday, October 7, 2004 12:13 PM -0600 Jean-Jacques Clar <[EMAIL PROTECTED]> wrote: I won't probably agree if we use 'Waboozle', and I suggest that the description should with the name of the module like MemCache* and DiskCache* to make it easier for related directives to be grouped together (sorted). I'd really prefer for all caching directives to be under Cache* so that the alphabetical ordering of the directives that we generate in our docs group them together. Using MemCache* and DiskCache* instead of CacheMem* and CacheDisk* sort of blow that away. (However, I won't fight this too hard, but just want to make my preference clear.) If we go through the process of renaming the directives (and I'm +1 to making it consistent per my first paragraph), I'd like to see us toss all of the directives we don't implement. My only worry there is that they will disappear forever instead of always annoying us every time we open the c file or look at the doc page. If we truly mean for it to be out of experimental, then it shouldn't have any no-op directives. That's exceedingly bad form, IMHO. BTW, are you volunteering to take the lead on this? ;-) -- justin Yes with pleasure, this is why I started the debate. Yay! -- justin
Re: mod_disk_cache directives naming convention
>>> [EMAIL PROTECTED] 10/07/04 11:14 AM >>> --On Thursday, October 7, 2004 9:08 AM -0600 Jean-Jacques Clar <[EMAIL PROTECTED]> wrote:>I *really* don't like the M prefix at all. I'd much prefer us to just spell >the thing out: CacheMem* and CacheDisk* instead of MCache and/or DCache. I >think a single letter prefix is really ambiguous. M what? I am not going to fight you on the prefix. I just want it to be different for each module, that is what I will like to get done here. I won't probably agree if we use 'Waboozle', and I suggest that the description should with the name of the module like MemCache* and DiskCache* to make it easier for related directives to be grouped together (sorted). >If we go through the process of renaming the directives (and I'm +1 to making >it consistent per my first paragraph), I'd like to see us toss all of the >directives we don't implement.My only worry there is that they will disappear forever instead of always annoying us every time we open the c file or look at the doc page. >BTW, are you volunteering to take the lead on this? ;-) -- justinYes with pleasure, this is why I started the debate. JJ
Re: mod_disk_cache directives naming convention
Justin Erenkrantz wrote: --On Thursday, October 7, 2004 7:21 PM +0200 Andreas Steinmetz <[EMAIL PROTECTED]> wrote: Not nice, IMHO. One major problem that prevents the use of apache 2.x for me is the fact that the cache size cannot be constrained. A cache that can grow without constraint can't be used on production systems. Feel free to submit a patch that efficiently allows the constraint of the cache size. I just don't see a way to do that as mod_disk_cache does not have any indexing. I'll have a look, though it will take a while. Whatever the result I'll post it. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
Re: mod_disk_cache directives naming convention
--On Thursday, October 7, 2004 7:21 PM +0200 Andreas Steinmetz <[EMAIL PROTECTED]> wrote: Not nice, IMHO. One major problem that prevents the use of apache 2.x for me is the fact that the cache size cannot be constrained. A cache that can grow without constraint can't be used on production systems. Feel free to submit a patch that efficiently allows the constraint of the cache size. I just don't see a way to do that as mod_disk_cache does not have any indexing. IMHO, instead of making a false promise, we should remove it. If we were to add such a feature later, we can add such directives accordingly. -- justin
Re: segfault in worker mpm
Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ -- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: mod_disk_cache directives naming convention
Justin Erenkrantz wrote: That said, there are a number of directives currently in mod_disk_cache that aren't implemented (and I don't see being implemented anytime soon): such as CacheSize, CacheGcInterval, CacheExpiryCheck, CacheTimeMargin, CacheGcDaily, CacheGcUnused, CacheGcClean, CacheGcMemUsage. If we go through the process of renaming the directives (and I'm +1 to making it consistent per my first paragraph), I'd like to see us toss all of the directives we don't implement. Not nice, IMHO. One major problem that prevents the use of apache 2.x for me is the fact that the cache size cannot be constrained. A cache that can grow without constraint can't be used on production systems. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
Bug: Apache hangs if script invokes fork/waitpid
The Problem:
---
I notice Apache 2(worker mpm) is not able to correctly handle
a fork/waitpid invoked by a script used with mod_perl.
Here is a simple cgi perl script to reproduce the problem (run under
mod_perl).
#!/opt/perl/bin/perl
print "Content-Type: text/plain; charset=euc-jp\n\n";
$pid=fork();
if( $pid == 0 ) {
sleep(15);
}
else {
waitpid($pid,0);
}
Run this cgi perl script under mod_perl (with ExecCGI option).
The call to fork in the perl script actually creates a child process
that is
identical to the Apache process currently handling the request. This
situation,
I believe, is somewhat different if the cgi script was run under
mod_cgi.
The forked child is not exactly identical to its parent
since the forked process only has the worker thread and no other threads
(i.e listner or the main thread waiting on POD or the other workers).
Now the funny thing is that once the forked process completes executing
the
remainder of the Perl script it returns back to the worker thread who
happily
goes back to ap_queue_pop waiting for someone to feed it more requests
to
handle...instead of terminating. And there is no one to feed it
anything.
Now the parent process (or perl script that invoked fork())
is performing a waitpid() for this child and thus blocked forever.
This effectively has made one worker thread useless. Invoking a second
request will
cause another worker thread to go down the drain and you can continue to
do this
till all worker process are put into a never ending wait. If Apache has
been constrained
by MaxClients to some value N, then N requests will efectively cause
Apache to
stop responding to further requests.
Essentially the forked Apache process does not know that it is not a
real Apache
worker process.
Fixing it:
-
First Solution :
The natural fix for this is to somehow make the forked worker aware that
it is not a real
worker and thus it should not go back to waiting for more requests once
its done. So
essentally in the worker_thread function we check if ap_my_pid ==
getpid() before continuing
into the next iteration of the while loop around ap_queue_pop().
ap_my_pid actually has the
pid of the (real) worker that forked the child worker.
static void * APR_THREAD_FUNC worker_thread(apr_thread_t *thd, void *
dummy)
{
// ... snip ...
while (!workers_may_exit)
{
// ... snip ...
worker_pop:
if (workers_may_exit) {
break;
}
/*break from loop if this worker was forked by another
worker*/
if ( ap_my_pid != getpid() ) {
break; // or apr_thread_exit(..) or exit(NULL);
}
rv = ap_queue_pop(worker_queue, &csd, &ptrans);
// ... snip ...
} // end while
// ... snip ..
}
However there is a problem with this approach. The connection is closed
(by the forked worker)
even before the next iteration of while loop. This causes a problem for
the parent who is
blocked on waitpid(). Consequently when the child returns control back
to the parent the parent
can no longer talk to the client. So the core_output_filter of the
parent prints out an error
message saying "broken pipe" in the error log.
It seems that the connection is closed by the worker in the apr_sendv()
function call itself !
So once the child has completed sending all its output, the connection
is closed immediately.
I thought it might be a better idea to invoke apr_thread_exit() instead
of break to prohibit
the forked worker from cleaning up any of the data structures that
actually belong to its
parent. But apr_thread_exit calls this..
...
apr_pool_destroy(thd->pool); // this cleans up stuff that belongs to
the parent!!
pthread_exit(NULL);
...
Second solution:
Is to invoke exit(0) (if we are in the forked worker) just after
ap_run_handler is invoked
by ap_invoke_handler
AP_CORE_DECLARE(int) ap_invoke_handler(request_rec *r)
|
{
// ...snip
result = ap_run_handler(r);
if ( I am a forked worker ) {
exit(0); // terminate at the earliest possible stage after
request was processed
}
// ...snip
}
Unfortunately this leaves us with a different problem (although a
smaller problem)
What happens here is that the forked child did all its request
processing, but never is not
given a chance to send any data out back to client(if it has any). But
then the catch-22 is
that if we allow it to send all its data out..then it will close the
connection too.
In summary:
Second solution seems preferrable among the two I have suggested.
If I had to chose between disallowing the parent or child from sending
data back, I would
disallow the child. Either way, parent is allowed to write stuff back
until the child closes
the connection. From my point of view, as forking is more useful for
performing time consuming
background tasks, rather t
Re: mod_disk_cache directives naming convention
--On Thursday, October 7, 2004 9:08 AM -0600 Jean-Jacques Clar <[EMAIL PROTECTED]> wrote: All the directives for mod_mem_cache are preceded with an "M". The ones for mod_cache are starting with a "c" Should all the disk_cache directives be preceded with a "D" for consistency and clarity? I know it is going to break every user configuration, but before the modules move out of experimental is probably the less painful time to do that change. I *really* don't like the M prefix at all. I'd much prefer us to just spell the thing out: CacheMem* and CacheDisk* instead of MCache and/or DCache. I think a single letter prefix is really ambiguous. M what? That said, there are a number of directives currently in mod_disk_cache that aren't implemented (and I don't see being implemented anytime soon): such as CacheSize, CacheGcInterval, CacheExpiryCheck, CacheTimeMargin, CacheGcDaily, CacheGcUnused, CacheGcClean, CacheGcMemUsage. If we go through the process of renaming the directives (and I'm +1 to making it consistent per my first paragraph), I'd like to see us toss all of the directives we don't implement. BTW, are you volunteering to take the lead on this? ;-) -- justin
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
Mladen Turk wrote: [snip] Both apr and libhttpd has more then 100 of those when /Wp64 is used, so IMO we would just hide the problems under carpet if just casting every 64->32 warning found. Agreed, hiding underlying problems is not acceptable. I am trying to address the many warnings that a Win64 build spits out in the correct way, not just for the sake of suppressing warnings. For example inside http_protocol.c you have: (i.e. in the current http_protocol.c code) 'int len = strlen(method)', that is wrong by all means, but I wouldn't write that as 'int len = (int)strlen(method)' just to make the compiler happy, but rather use 'size_t len = strlen(method)'. Agreed. In the patch just posted you'll see mod_win32.c takes the approach you suggest, as does a patch I have been working on that addresses http_protocol.c and other warnings. I will be posting this shortly. Well, that one is probably OK. I was talking about the concept of not casting just for the sake of making compiler happy. Agree. Thanks, Allan
mod_disk_cache directives naming convention
All the directives for mod_mem_cache are preceded with an "M". The ones for mod_cache are starting with a "c" Should all the disk_cache directives be preceded with a "D" for consistency and clarity? I know it is going to break every user configuration, but before the modules move out of experimental is probably the less painful time to do that change. Thanks, JJ
Re: segfault in worker mpm
I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Bye bye welcome page
> > If I was a newbie, and I saw a page that says `it worked`, my immediate > > reaction would be `what worked?` and I would start asking the exact > > questions we`re trying to stop people from asking. > > We can always go with simply displaying a meaningless word like 'Waboozle'. And so the madness begins again.. Let's just trust Josh to come up with a really short message like "Your web server installation has succeeded, now you need to write some content." or "It worked!". And yes, it's only in english. At the end of the day, if somebody can't work out what that means who's going to want to read their pages anyway? :-) John
